In the java libraries there are many methods that operate on byte arrays
that do not allow you to specify offset and length for the relevant data
instead forcing you to copy the relevant part to new arrays before using
the methods reducing performance - I am for instance struggling with this
in jav
On Tue, 21 May 2024 14:28:38 GMT, Matthias Baesken wrote:
> When building with ubsan enabled (--enable-uban) on Linux x86_64 and doing
> jtreg tests afterwards I run into this error :
>
> /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c:562:5: runtime error:
> null pointer passed as arg
On Thu, 4 Apr 2024 20:52:59 GMT, Magnus Ihse Bursie wrote:
>> Severin Gehwolf has updated the pull request incrementally with three
>> additional commits since the last revision:
>>
>> - Use shorter name for the build tool
>> - Review feedback from Erik J.
On Wed, 22 May 2024 07:42:39 GMT, Magnus Ihse Bursie wrote:
>> src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties line
>> 165:
>>
>>> 163:
>>> 164: runtime.link.info=Linking based on the current run-time image.
>>> 165:
On Wed, 22 May 2024 07:44:08 GMT, Magnus Ihse Bursie wrote:
>> ... still missing...
>
> Actually, this is a bit strange. I thought jcheck would look for missing
> newline at EOF, and that properties files were included in the check
> nowadays. I'll need to check this o
On Tue, 21 May 2024 20:28:37 GMT, Joe Wang wrote:
>> Add two sample configuration files:
>>
>> jaxp-strict.properties: used to set strict configuration, stricter than
>> jaxp.properties in previous versions such as JDK 22
>>
>>> jaxp-compat.properties: used to regain compatibility from any
On Fri, 17 May 2024 13:38:25 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loa
On Thu, 23 May 2024 07:26:14 GMT, Matthias Baesken wrote:
>> When building with ubsan enabled (--enable-uban) on Linux x86_64 and doing
>> jtreg tests afterwards I run into this error :
>>
>> /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c:562:5: runtime
>> error: null pointer passed a
On Thu, 23 May 2024 11:39:11 GMT, Per Minborg wrote:
> This PR proposes to fix a broken link in the `MemorySegment.Scope` class.
The fix looks fine but the bug title sounds like you are modifying an html
file...
-
PR Comment: https://git.openjdk.org/jdk/pull/19366#issuecomment-212
On Thu, 23 May 2024 07:26:14 GMT, Matthias Baesken wrote:
>> When building with ubsan enabled (--enable-uban) on Linux x86_64 and doing
>> jtreg tests afterwards I run into this error :
>>
>> /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c:562:5: runtime
>> error: null pointer passed a
On Fri, 24 May 2024 07:24:13 GMT, Matthias Baesken wrote:
>> When building with ubsan enabled (--enable-uban) on Linux x86_64 and doing
>> jtreg tests afterwards I run into this error :
>>
>> /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c:562:5: runtime
>> error: null pointer passed a
On Fri, 24 May 2024 05:26:40 GMT, Joe Wang wrote:
>> Add two sample configuration files:
>>
>> jaxp-strict.properties: used to set strict configuration, stricter than
>> jaxp.properties in previous versions such as JDK 22
>>
>>> jaxp-compat.properties: used to regain compatibility from any
On Fri, 24 May 2024 16:36:32 GMT, Joe Wang wrote:
>> Add two sample configuration files:
>>
>> jaxp-strict.properties: used to set strict configuration, stricter than
>> jaxp.properties in previous versions such as JDK 22
>>
>>> jaxp-compat.properties: used to regain compatibility from any
The original way of building static libraries in the JDK was to use the
configure argument --enable-static-build, which set the value of the make
variable STATIC_BUILD. (Note that this is not the same as the source code
definition STATIC_BUILD, which will be set by other means as well.)
This me
On Thu, 30 May 2024 19:14:43 GMT, Magnus Ihse Bursie wrote:
> The original way of building static libraries in the JDK was to use the
> configure argument --enable-static-build, which set the value of the make
> variable STATIC_BUILD. (Note that this is not the same as the so
On Mon, 3 Jun 2024 19:10:22 GMT, Alan Bateman wrote:
> Does that proposal sound good?
What you basically is saying is that the default value of `packaged-modules`
should be `! runtime-link-image` (i.e. the inverse)?
-
PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment
On Wed, 5 Jun 2024 17:31:44 GMT, Severin Gehwolf wrote:
>> Please review this patch which adds a jlink mode to the JDK which doesn't
>> need the packaged modules being present. A.k.a run-time image based jlink.
>> Fundamentally this patch adds an option to use `jlink` even though your JDK
>> i
On Thu, 6 Jun 2024 09:47:30 GMT, Severin Gehwolf wrote:
>> Please review this patch which adds a jlink mode to the JDK which doesn't
>> need the packaged modules being present. A.k.a run-time image based jlink.
>> Fundamentally this patch adds an option to use `jlink` even though your JDK
>> i
On Thu, 2 May 2024 09:48:51 GMT, Christian Stein wrote:
> Please review the change to update to using `jtreg` **7.4**.
>
> 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 `requiredV
On Fri, 7 Jun 2024 13:34:45 GMT, Julian Waters wrote:
>> I find the extra trailing newlines through below shell command:
>>
>> for i in `find . -iname "Makefile*" | sed "/./build/d"` ; do tail -n 2 $i |
>> grep -c "^$" | grep -q "^1$" ; if [[ 0 -eq $? ]] ; then echo $i ; fi ; done
>>
>>
>> Th
This patch contains a set of changes to improve static builds. They will pave
the way for implementing a full static-only java launcher. The changes here
will:
1) Make sure non-exported symbols are made local in the static libraries. This
means that the risk of symbol conflict is the same for s
On Thu, 30 May 2024 13:00:21 GMT, Magnus Ihse Bursie wrote:
> This patch contains a set of changes to improve static builds. They will pave
> the way for implementing a full static-only java launcher. The changes here
> will:
>
> 1) Make sure non-exported symbols are made loca
On Thu, 30 May 2024 13:00:21 GMT, Magnus Ihse Bursie wrote:
> This patch contains a set of changes to improve static builds. They will pave
> the way for implementing a full static-only java launcher. The changes here
> will:
>
> 1) Make sure non-exported symbols are made loca
libraries that did not work properly
> with a static java launcher.
>
> The latter fixes are copied from or inspired by the work done by @jianglizhou
> and her team as part of the Project Leyden [Hermetic
> Java](https://github.com/openjdk/leyden/tree/hermetic-java-runtime).
Mag
On Thu, 30 May 2024 19:35:44 GMT, Magnus Ihse Bursie wrote:
> Do os::lookup_function need to be implemented on Windows too, for symmetry,
> even if it is only used on Unix platforms?
@AlanBateman suggested to add `lookup_function` to os_windows.cpp as well, but
just let it c
On Tue, 18 Jun 2024 16:19:39 GMT, Magnus Ihse Bursie wrote:
>> This patch contains a set of changes to improve static builds. They will
>> pave the way for implementing a full static-only java launcher. The changes
>> here will:
>>
>> 1) Make sure non-exported
On Tue, 18 Jun 2024 16:30:37 GMT, Jorn Vernee wrote:
> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
> code that accesses native functionality. Currently this includes `native`
> method declarations, and methods marked with `@Restricted`.
>
> The tool accepts a li
libraries that did not work properly
> with a static java launcher.
>
> The latter fixes are copied from or inspired by the work done by @jianglizhou
> and her team as part of the Project Leyden [Hermetic
> Java](https://github.com/openjdk/leyden/tree/hermetic-java-runtime
libraries that did not work properly
> with a static java launcher.
>
> The latter fixes are copied from or inspired by the work done by @jianglizhou
> and her team as part of the Project Leyden [Hermetic
> Java](https://github.com/openjdk/leyden/tree/hermetic-java-runtime
On Wed, 19 Jun 2024 15:15:43 GMT, Magnus Ihse Bursie wrote:
>> This patch contains a set of changes to improve static builds. They will
>> pave the way for implementing a full static-only java launcher. The changes
>> here will:
>>
>> 1) Make sure non-exported
On Fri, 26 Jul 2024 19:40:24 GMT, Brian Burkhalter wrote:
>> This proposed change would move the native objects required for NIO file
>> interaction from the libnio native library to the libjava native library on
>> Linux, macOS, and Windows.
>
> Brian Burkhalter has updated the pull request in
On Wed, 7 Aug 2024 15:56:06 GMT, Brian Burkhalter wrote:
>> This proposed change would move the native objects required for NIO file
>> interaction from the libnio native library to the libjava native library on
>> Linux, macOS, and Windows.
>
> Brian Burkhalter has updated the pull request wit
On Wed, 7 Aug 2024 18:13:25 GMT, Brian Burkhalter wrote:
>> `CoreServices` is still necessary ([Uniform Type
>> Identifier](https://developer.apple.com/documentation/uniformtypeidentifiers)s).
>
> The Windows libs are also still required for `TransmitFile` and
> `WSAGetLastError`:
>
> - ```msw
On Thu, 8 Aug 2024 16:29:18 GMT, Brian Burkhalter wrote:
>> I will check.
>
> `pthread` is still needed:
>
> open/src/java.base/unix/native/libjava/nio/ch/NativeThread.c:83: error:
> undefined reference to 'pthread_kill'
Ok then. Thank you for your thorough checking!
-
PR Review
On Fri, 9 Aug 2024 17:59:12 GMT, Brian Burkhalter wrote:
>> This proposed change would move the native objects required for NIO file
>> interaction from the libnio native library to the libjava native library on
>> Linux, macOS, and Windows.
>
> Brian Burkhalter has updated the pull request inc
As a preparation for Hermetic Java, we need to have a way to look up during
runtime if we are using a statically linked library or not.
This change will be the first step needed towards compiling the object files
only once, and then link them into either dynamic or static libraries. (The
only e
> https://github.com/openjdk/jdk/pull/19478, which I have broken out.
Magnus Ihse Bursie has updated the pull request incrementally with one
additional commit since the last revision:
Also update build to link properly
-
Changes:
- all: https://git.openjdk.org/jd
On Thu, 22 Aug 2024 00:30:07 GMT, Jiangli Zhou wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Also update build to link properly
>
> I compared the extracted changes in thi
On Thu, 22 Aug 2024 02:46:34 GMT, David Holmes wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Also update build to link properly
>
> Sorry but I don't understand the poin
On Thu, 22 Aug 2024 22:49:50 GMT, David Holmes wrote:
> is the final intent here that this one magic file will be compiled first with
> an inline declaration such that when the other files containing the apparent
> runtime check get compiled, it can actually be determined at build time and
> s
On Sun, 25 Aug 2024 14:57:22 GMT, Alan Bateman wrote:
> That is true for now but there 30-50 other places that will need attention
> once this effort is further along. Everywhere that deals with user editable
> configuration (conf tree) will change, as will everywhere that reads JDK
> internal
On Mon, 26 Aug 2024 02:07:39 GMT, David Holmes wrote:
> but it still impacts every single Java run just to save some time/resources
> for the handful of builders of statically linked VMs.
Seriously? I challenge you do prove there is any effect at all. :-/
Also, there is not a "handful" of buil
On Mon, 26 Aug 2024 09:39:28 GMT, Magnus Ihse Bursie wrote:
>> I understand the cost overhead experienced by any individual Java run may be
>> lost in the noise, but it still impacts every single Java run just to save
>> some time/resources for the handful of builders of sta
On Wed, 21 Aug 2024 22:14:40 GMT, Magnus Ihse Bursie wrote:
>> As a preparation for Hermetic Java, we need to have a way to look up during
>> runtime if we are using a statically linked library or not.
>>
>> This change will be the first step needed towards compiling t
Currently, we issue -Wno-unused for all files in gcc, which is a rather big
sledgehammer to get rid of some warnings that proliferate in a few areas of the
build.
We should instead leave -Wunused turned on (as done by -Wall) and use a much
more fine-grained approach to disabling specific warnin
On Tue, 27 Aug 2024 20:04:21 GMT, Magnus Ihse Bursie wrote:
> Currently, we issue -Wno-unused for all files in gcc, which is a rather big
> sledgehammer to get rid of some warnings that proliferate in a few areas of
> the build.
>
> We should instead leave -Wunused turned on (a
On Wed, 28 Aug 2024 06:38:48 GMT, Kim Barrett wrote:
> We should make a similar set of changes for clang, though doing that in a
> separate
proposal is good. Is there a JBS issue for that yet?
Yes, we should. I am 80% done with that patch, but I have not yet opened a JBS
ticket. Will do that n
roach to disabling specific warnings in specific files
> or libraries.
Magnus Ihse Bursie has updated the pull request incrementally with one
additional commit since the last revision:
Use -Wunused-const-variable=1 instead
-
Changes:
- all: https://git.openjdk.org/jdk/pul
On Wed, 28 Aug 2024 11:26:01 GMT, Magnus Ihse Bursie wrote:
>> make/autoconf/flags-cflags.m4 line 239:
>>
>>> 237: # Additional warnings that are not activated by -Wall and -Wextra
>>> 238: WARNINGS_ENABLE_ADDITIONAL="-Wpointer-arith -Wreturn
On Tue, 27 Aug 2024 23:15:03 GMT, Jiangli Zhou wrote:
>> And the discussion whether the checks are made "dynamically" or "statically"
>> is too simplified to be really helpful.
>>
>> Currently, we compile two sets of all object files, with slightly different
>> compiler arguments, one for dyna
roach to disabling specific warnings in specific files
> or libraries.
Magnus Ihse Bursie has updated the pull request incrementally with one
additional commit since the last revision:
Fix aarch54
-
Changes:
- all: https://git.openjdk.org/jdk/pull/20733/files
- new: https:
roach to disabling specific warnings in specific files
> or libraries.
Magnus Ihse Bursie has updated the pull request incrementally with one
additional commit since the last revision:
Fix ppc64
-
Changes:
- all: https://git.openjdk.org/jdk/pull/20733/files
- new: https://git
On Wed, 28 Aug 2024 12:29:36 GMT, Magnus Ihse Bursie wrote:
>> Good point, I'll try that.
>
> It turned out to be sort-of okay-ish. I explicitly listed like 6 or so
> per-file exclusions in Hotspot (even though my normal cutoff for just setting
> a component-wide exclude
On Wed, 28 Aug 2024 13:35:19 GMT, Kim Barrett wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix aarch54
>
> make/modules/java.desktop/lib/ClientLibraries.gmk line
roach to disabling specific warnings in specific files
> or libraries.
Magnus Ihse Bursie has updated the pull request incrementally with one
additional commit since the last revision:
Fix s390x build
-
Changes:
- all: https://git.openjdk.org/jdk/pull/20733/files
- new: ht
roach to disabling specific warnings in specific files
> or libraries.
Magnus Ihse Bursie has updated the pull request incrementally with one
additional commit since the last revision:
Roll back indentation fix
-
Changes:
- all: https://git.openjdk.org/jdk/pull/20733
On Tue, 27 Aug 2024 20:04:21 GMT, Magnus Ihse Bursie wrote:
> Currently, we issue -Wno-unused for all files in gcc, which is a rather big
> sledgehammer to get rid of some warnings that proliferate in a few areas of
> the build.
>
> We should instead leave -Wunused turned on (a
On Wed, 21 Aug 2024 22:14:40 GMT, Magnus Ihse Bursie wrote:
>> As a preparation for Hermetic Java, we need to have a way to look up during
>> runtime if we are using a statically linked library or not.
>>
>> This change will be the first step needed towards compiling t
Currently, we issue -Wno-unused for all files in clang, which is a rather big
sledgehammer to get rid of some warnings that proliferate in a few areas of the
build.
We should instead leave -Wunused turned on (as done by -Wall) and use a much
more fine-grained approach to disabling specific warn
On Thu, 29 Aug 2024 18:44:22 GMT, Kim Barrett wrote:
>> Currently, we issue -Wno-unused for all files in clang, which is a rather
>> big sledgehammer to get rid of some warnings that proliferate in a few areas
>> of the build.
>>
>> We should instead leave -Wunused turned on (as done by -Wall)
On Mon, 26 Aug 2024 02:07:39 GMT, David Holmes wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Also update build to link properly
>
> I understand the cost overhead experienced
roach to disabling specific warnings in specific files
> or libraries.
>
> This is similar to what has been done for gcc in JDK-8339120.
Magnus Ihse Bursie has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains two commits:
-
On Thu, 29 Aug 2024 13:14:35 GMT, Magnus Ihse Bursie wrote:
> Currently, we issue -Wno-unused for all files in clang, which is a rather big
> sledgehammer to get rid of some warnings that proliferate in a few areas of
> the build.
>
> We should instead leave -Wunused turned
On Thu, 29 Aug 2024 13:14:35 GMT, Magnus Ihse Bursie wrote:
> Currently, we issue -Wno-unused for all files in clang, which is a rather big
> sledgehammer to get rid of some warnings that proliferate in a few areas of
> the build.
>
> We should instead leave -Wunused turned
On Wed, 21 Aug 2024 21:53:39 GMT, Magnus Ihse Bursie wrote:
> As a preparation for Hermetic Java, we need to have a way to look up during
> runtime if we are using a statically linked library or not.
>
> This change will be the first step needed towards compiling the object files
On Mon, 2 Sep 2024 20:06:06 GMT, Martin Doerr wrote:
>> Matthias Baesken has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> adjust indentation in X11Color.c
>
> src/java.desktop/unix/native/common/awt/X11Color.c line 1234:
>
>> 1232: awt_a
On Mon, 2 Sep 2024 13:25:51 GMT, Matthias Baesken wrote:
>> We get a couple of warnings as errors on AIX because of unused variables or
>> functions , for example :
>> /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c
On Tue, 3 Sep 2024 02:25:16 GMT, David Holmes wrote:
> Also doesn't a call like this trigger the warning about ignoring a function
> result, or have we disabled that one?
Such a warning would be horrible to have enable. Then you would have to read
the value of every function that thought it sh
As a prerequisite for Hermetic Java, we need a statically linked `java`
launcher. It should behave like the normal, dynamically linked `java` launcher,
except that all JDK native libraries should be statically, not dynamically,
linked.
This patch is the first step towards this goal. It will gen
On Tue, 3 Sep 2024 12:50:01 GMT, Magnus Ihse Bursie wrote:
> As a prerequisite for Hermetic Java, we need a statically linked `java`
> launcher. It should behave like the normal, dynamically linked `java`
> launcher, except that all JDK native libraries should be statically, not
>
On Fri, 30 Sep 2022 01:11:45 GMT, Joe Darcy wrote:
>> With the domain change from openjdk.java.net to openjdk.org, references to
>> URLs in the sources should be updated.
>>
>> Updates were made using a shell script. I"ll run a copyright updater before
>> any push.
>
> Joe Darcy has updated th
On Mon, 26 Sep 2022 15:31:53 GMT, Magnus Ihse Bursie wrote:
> After [JDK-8294281](https://bugs.openjdk.org/browse/JDK-8294281), it is now
> possible to disable warnings for individual files instead for whole
> libraries. I used this opportunity to go through all disabled wa
On Mon, 3 Oct 2022 20:37:11 GMT, Joe Darcy wrote:
>> With the domain change from openjdk.java.net to openjdk.org, references to
>> URLs in the sources should be updated.
>>
>> Updates were made using a shell script. I"ll run a copyright updater before
>> any push.
>
> Joe Darcy has updated the
Markdown files are basically source code for documentation. It should have the
same whitespace checks as all other source code, so we don't get spurious
trailing whitespace changes.
-
Commit messages:
- 8295205: Add jcheck whitespace checking for markdown files
Changes: https://gi
On Wed, 12 Oct 2022 09:44:54 GMT, Magnus Ihse Bursie wrote:
> Markdown files are basically source code for documentation. It should have
> the same whitespace checks as all other source code, so we don't get spurious
> trailing whitespace changes.
This pull request has now b
On Mon, 10 Oct 2022 14:15:37 GMT, Julian Waters wrote:
> Some external libraries required by native code are linked via linker
> comments embedded in pragmas. Searching for which libraries are linked can
> then become frustrating and confusing since they may be included in an
> obscure place,
This is a continuation of the effort to update all our URLs to the new
top-level domain.
This patch updates (most) URLs in testing code. There still exists references
to openjdk.java.net, but that are not strictly used as normal URLs, which I
deemed need special care, so I left them out of this
On Tue, 18 Oct 2022 11:55:06 GMT, Magnus Ihse Bursie wrote:
> This is a continuation of the effort to update all our URLs to the new
> top-level domain.
>
> This patch updates (most) URLs in testing code. There still exists references
> to openjdk.java.net, but that are not s
On Tue, 18 Oct 2022 11:55:06 GMT, Magnus Ihse Bursie wrote:
> This is a continuation of the effort to update all our URLs to the new
> top-level domain.
>
> This patch updates (most) URLs in testing code. There still exists references
> to openjdk.java.net, but that are not s
Properties files is essentially source code. It should have the same whitespace
checks as all other source code, so we don't get spurious trailing whitespace
changes.
With the new Skara jcheck, it is possible to increase the coverage of the
whitespace checks (in the old mercurial version, this
On Thu, 20 Oct 2022 18:38:43 GMT, Andy Goryachev wrote:
>> Properties files is essentially source code. It should have the same
>> whitespace checks as all other source code, so we don't get spurious
>> trailing whitespace changes.
>>
>> With the new Skara jcheck, it is possible to increase th
On Thu, 20 Oct 2022 11:58:58 GMT, Magnus Ihse Bursie wrote:
> Properties files is essentially source code. It should have the same
> whitespace checks as all other source code, so we don't get spurious trailing
> whitespace changes.
>
> With the new Skara jcheck, it is
s (in the old mercurial version, this was more or less
> impossible).
>
> The only manual change is to `.jcheck/conf`. All other changes were made by
> running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[
> \t]*$//'`.
Magnus Ihse Bursie has u
On Fri, 21 Oct 2022 08:17:46 GMT, Magnus Ihse Bursie wrote:
>> Properties files is essentially source code. It should have the same
>> whitespace checks as all other source code, so we don't get spurious
>> trailing whitespace changes.
>>
>> With the
s (in the old mercurial version, this was more or less
> impossible).
>
> The only manual change is to `.jcheck/conf`. All other changes were made by
> running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[
> \t]*$//'`.
Magnus Ihse Bursie has u
On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie wrote:
>> Properties files is essentially source code. It should have the same
>> whitespace checks as all other source code, so we don't get spurious
>> trailing whitespace changes.
>>
>> With the
On Mon, 24 Oct 2022 19:20:24 GMT, Andy Goryachev wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Remove check for .properties from jcheck
>> - Restore trailing whitespace for
On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie wrote:
>> Properties files is essentially source code. It should have the same
>> whitespace checks as all other source code, so we don't get spurious
>> trailing whitespace changes.
>>
>> With the
On Mon, 24 Oct 2022 19:39:21 GMT, Jonathan Gibbons wrote:
> I think it would be better to try and remove incidental trailing whitespace
> first, before encoding any remaining whitespace. Hiding the trailing
> whitespace as a Unicode escape seems like a bad idea, equivalent to sweeping
> the is
On Fri, 4 Nov 2022 12:38:04 GMT, Adam Sotona wrote:
> This is root pull request with Classfile API implementation, tests and
> benchmarks initial drop into JDK.
>
> Following pull requests consolidating JDK class files parsing, generating,
> and transforming ([JDK-8294957](https://bugs.openjdk
On Fri, 4 Nov 2022 12:38:04 GMT, Adam Sotona wrote:
> This is root pull request with Classfile API implementation, tests and
> benchmarks initial drop into JDK.
>
> Following pull requests consolidating JDK class files parsing, generating,
> and transforming ([JDK-8294957](https://bugs.openjdk
On Mon, 7 Nov 2022 12:10:56 GMT, Magnus Ihse Bursie wrote:
>> This is root pull request with Classfile API implementation, tests and
>> benchmarks initial drop into JDK.
>>
>> Following pull requests consolidating JDK class files parsing, generating,
>> and
On Mon, 7 Nov 2022 12:45:00 GMT, Adam Sotona wrote:
>> make/test/BuildMicrobenchmark.gmk line 106:
>>
>>> 104: --add-exports java.base/jdk.classfile.components=ALL-UNNAMED \
>>> 105: --add-exports java.base/jdk.classfile.impl=ALL-UNNAMED \
>>> 106: --add-exports
>>> java
On Mon, 7 Nov 2022 12:52:38 GMT, Adam Sotona wrote:
>> To be more specific: is there some way the code in Preview.java and
>> TransPatterns.java can be modified so this transmogrification is not needed?
>
> Patched interim Preview and TransPatterns is a temporary workaround to allow
> internal
On Fri, 25 Nov 2022 15:18:09 GMT, Adam Sotona wrote:
>> I'll fix it, thanks.
>
> Unfortunately I found only two use cases of external snippets in JDK. One is
> explicitly excluding the snippets package and the other does not care, so the
> snippets are included.
Is the practice of naming the d
On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie wrote:
>> Properties files is essentially source code. It should have the same
>> whitespace checks as all other source code, so we don't get spurious
>> trailing whitespace changes.
>>
>> With the
test/micro/org/openjdk/bench/java/lang/foreign/libQSortJNI.c is missing the
correct macro definition to compile on 32-bit Windows.
-
Commit messages:
- 8297853: windows-x86 test build broken
Changes: https://git.openjdk.org/jdk/pull/11434/files
Webrev: https://webrevs.openjdk.org/
> test/micro/org/openjdk/bench/java/lang/foreign/libQSortJNI.c is missing the
> correct macro definition to compile on 32-bit Windows.
Magnus Ihse Bursie has updated the pull request incrementally with one
additional commit since the last revision:
Use only _WIN32
-
C
On Wed, 30 Nov 2022 15:58:17 GMT, Magnus Ihse Bursie wrote:
> test/micro/org/openjdk/bench/java/lang/foreign/libQSortJNI.c is missing the
> correct macro definition to compile on 32-bit Windows.
This pull request has now been integrated.
Changeset: 6bac3323
Author:Magnus Ihse Bursi
According to [the
specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader))
trailing whitespaces in the values of properties files are (somewhat
surprisingly) actually significant.
We have multiple files in the JDK with trailing
1 - 100 of 775 matches
Mail list logo
