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
>>
>>
>>
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
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
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
On Thu, 9 May 2024 07:50:00 GMT, Julian Waters wrote:
>> WIP
>>
>> This changeset contains hsdis for Windows/gcc Port. It supports both the
>> binutils and capstone backends, though the LLVM backend is left out due to
>> compatibility issues encountered during the build. Currently, which gcc
On 2024-05-15 02:13, Nizar Benalla wrote:
Hello,
I discovered after some recent work around javadoc that `javac` does
not recognize `package.html` files, which predate `package-info.java`.
Some tools that want to analyze doc comments need to deal with this in
special ways.
Maybe optional
On Tue, 23 Apr 2024 13:56:32 GMT, Julian Waters wrote:
> WIP
>
> This changeset contains hsdis for Windows/gcc Port. It supports both the
> binutils and capstone backends, though the LLVM backend is left out due to
> compatibility issues encountered during the build. Currently, which gcc
>
On Tue, 23 Apr 2024 13:56:32 GMT, Julian Waters wrote:
> WIP
>
> This changeset contains hsdis for Windows/gcc Port. It supports both the
> binutils and capstone backends, though the LLVM backend is left out due to
> compatibility issues encountered during the build. Currently, which gcc
>
On Wed, 27 Mar 2024 22:04:30 GMT, Jonathan Gibbons wrote:
> Please review the updates to support a proposed new
> `-Xlint:dangling-doc-comments` option.
>
> The work can be thought of as in 3 parts:
>
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it
> is possible
Similar to [JDK-8328157](https://bugs.openjdk.org/browse/JDK-8328157), we want
to move the setting of LDFLAGS to LDFLAGS_JDK[LIB/EXE into SetupJdkLibrary and
SetupJdkExecutable.
-
Commit messages:
- 8328177: Move LDFLAGS_JDK[LIB/EXE] to JdkNativeCompilation.gmk
Changes:
We are setting one of the flags `CFLAGS_JDKLIB`, `CXXFLAGS_JDKLIB`,
`CFLAGS_JDKEXE` or `CXXFLAGS_JDKEXE` to `CFLAGS` or `CXXFLAGS`, respectively,
in basically all calls to `SetupJdkLibrary` and `SetupJdkExecutable`.
These flag variables contain a lot of duplication.
The first step towards
On Thu, 14 Mar 2024 12:36:05 GMT, Magnus Ihse Bursie wrote:
> We are setting one of the flags `CFLAGS_JDKLIB`, `CXXFLAGS_JDKLIB`,
> `CFLAGS_JDKEXE` or `CXXFLAGS_JDKEXE` to `CFLAGS` or `CXXFLAGS`, respectively,
> in basically all calls to `SetupJdkLibrary` and `SetupJdkE
We are adding LIBCXX to LIBS in calls to SetupJdkLibrary whenever LINK_TYPE is
C++. We should do this automatically in SetupJdkLibrary for C++ linking.
I also removed the superfluous `-lc` from some places where it had been added.
-
Commit messages:
- 8328146: Set LIBCXX
On Tue, 27 Feb 2024 11:19:59 GMT, Magnus Ihse Bursie wrote:
>> The idea of setting up general "toolchains" in the native build was good,
>> but it turned out that we really only need a single toolchain, with a single
>> twist: if it should use CC or CPP to li
On Tue, 5 Mar 2024 08:48:15 GMT, Martin Doerr wrote:
>> Suchismith Roy has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> indendt
>
> jdk21u is only open for critical backports and requires special approval.
> Please backport it to
On Mon, 4 Mar 2024 11:45:59 GMT, Julian Waters wrote:
> I do hope that dropping ccache support isn't something that's planned though
> :(
Not really. The benefit of dropping it is quite small, and there might be use
cases where it helps.
But I think we should perhaps be more explicit in the
On Mon, 4 Mar 2024 06:42:30 GMT, Julian Waters wrote:
> I wonder if it's the SetupToolchain changes that has caused this. ccache is
> collapsed into CC and CXX to my knowledge
Yeah, it must have been. Would you like to take a look at it? Otherwise I'll
file a bug and fix it. Breaking ccache
On Tue, 27 Feb 2024 11:19:59 GMT, Magnus Ihse Bursie wrote:
>> The idea of setting up general "toolchains" in the native build was good,
>> but it turned out that we really only need a single toolchain, with a single
>> twist: if it should use CC or CPP to li
On Tue, 27 Feb 2024 11:19:59 GMT, Magnus Ihse Bursie wrote:
>> The idea of setting up general "toolchains" in the native build was good,
>> but it turned out that we really only need a single toolchain, with a single
>> twist: if it should use CC or CPP to li
On Tue, 27 Feb 2024 11:44:31 GMT, Daniel Jeliński wrote:
> FWIW, when I added -lstdc++ before both -static-libstdc++ and replaced LDCXX
> with LD, the code compiled and linked just fine.
Both GCC and G++ call the same linker, and the parameter differences are well
documented. It's only a
e SetupNativeCompilation code, and
> make it much clearer if we use the C or C++ linker.
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 five commits:
- Merge branch 'master' into remove-toolchain-define
- Rena
On Fri, 23 Feb 2024 16:23:43 GMT, Magnus Ihse Bursie wrote:
> The idea of setting up general "toolchains" in the native build was good, but
> it turned out that we really only need a single toolchain, with a single
> twist: if it should use CC or CPP to link. This
On Tue, 27 Feb 2024 08:14:56 GMT, Julian Waters wrote:
> can we get rid of LDCXX?
Yeah, that is something I plan to look into. Linking C++ object files with gcc
will fail; and it might be that linking pure C with g++ might be problematic.
If this is the case, I hope we can at least determine
On Tue, 27 Feb 2024 08:29:44 GMT, Julian Waters wrote:
> All those new parameters to SetupNativeCompilation, were they always there
> and the comments about them were just missing from the documentation about
> the function?
Yep. The toolchain definition was a way to "package" multiple
On Sat, 24 Feb 2024 06:04:40 GMT, Julian Waters wrote:
>> The idea of setting up general "toolchains" in the native build was good,
>> but it turned out that we really only need a single toolchain, with a single
>> twist: if it should use CC or CPP to link. This is better described by a
>>
e SetupNativeCompilation code, and
> make it much clearer if we use the C or C++ linker.
Magnus Ihse Bursie has updated the pull request incrementally with one
additional commit since the last revision:
Rename LANG to LINK_TYPE
-
Changes:
- all: https://git.openjdk.org/jdk/pul
e SetupNativeCompilation code, and
> make it much clearer if we use the C or C++ linker.
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 three commits:
- Reword "lib" comment to fit in better
- Mer
On Fri, 23 Feb 2024 16:23:43 GMT, Magnus Ihse Bursie wrote:
> The idea of setting up general "toolchains" in the native build was good, but
> it turned out that we really only need a single toolchain, with a single
> twist: if it should use CC or CPP to link. This
On Fri, 23 Feb 2024 16:23:43 GMT, Magnus Ihse Bursie wrote:
> The idea of setting up general "toolchains" in the native build was good, but
> it turned out that we really only need a single toolchain, with a single
> twist: if it should use CC or CPP to link. This
On Fri, 23 Feb 2024 16:23:43 GMT, Magnus Ihse Bursie wrote:
> The idea of setting up general "toolchains" in the native build was good, but
> it turned out that we really only need a single toolchain, with a single
> twist: if it should use CC or CPP to link. This
The idea of setting up general "toolchains" in the native build was good, but
it turned out that we really only need a single toolchain, with a single twist:
if it should use CC or CPP to link. This is better described by a specific
argument to SetupNativeCompilation, LANG := C++ or LANG := C
On Thu, 15 Feb 2024 12:19:31 GMT, Magnus Ihse Bursie wrote:
> Since jcheck only checks file in a commit, there is a possibility of us
> getting files in the repository that would not be accepted by jcheck. This
> can happen when extending the set of files checked by jcheck, or
On 2024-02-18 11:15, Andrew Haley wrote:
On 2/14/24 10:06, Magnus Ihse Bursie wrote:
My takeaway from the discussions is that we are most likely exporting a
way too broad set of symbols to SA. It seems likely that this set can be
drastically cut down. Actually getting an understanding
On Thu, 15 Feb 2024 17:53:41 GMT, Naoto Sato wrote:
>> `\u000b` is VT (vertical tab)
>> `\u0009` or `\t` perhaps?
>
> Right. `\t` is better to avoid such a mistake.
Ok, fixed.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/17871#discussion_r1492403403
xes).
>
> I have now run jcheck over the entire code base, and fixed a handful of
> issues. With these changes, jcheck accept the entire code base.
Magnus Ihse Bursie has updated the pull request incrementally with one
additional commit since the last revision:
Replace spaces with \t in
On Thu, 15 Feb 2024 14:01:46 GMT, Erik Joelsson wrote:
>> test/jdk/java/util/Currency/currency.properties line 18:
>>
>>> 16: SB=EUR,111,2, 2099-01-01T00:00:00
>>> 17: US=euR,978,2,2001-01-01T00:00:00
>>> 18: ZZ = ZZZ , 999 , 3
>>
>> This looks weird, but so did
On Thu, 15 Feb 2024 12:19:31 GMT, Magnus Ihse Bursie wrote:
> Since jcheck only checks file in a commit, there is a possibility of us
> getting files in the repository that would not be accepted by jcheck. This
> can happen when extending the set of files checked by jcheck, or
Since jcheck only checks file in a commit, there is a possibility of us getting
files in the repository that would not be accepted by jcheck. This can happen
when extending the set of files checked by jcheck, or if jcheck changes how it
checks files (perhaps due to bug fixes).
I have now run
On Mon, 12 Feb 2024 12:43:09 GMT, Magnus Ihse Bursie wrote:
> There are several places in hotspot where an internal function should have
> been declared static, but isn't.
>
> These were discovered by trying to use the gcc option
> `-Wmissing-declarations` and the correspondi
On Mon, 12 Feb 2024 16:47:59 GMT, Stefan Karlsson wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Revert spurious changes in non-modified file
>> - Fix indentation iss
On Mon, 12 Feb 2024 16:47:59 GMT, Stefan Karlsson wrote:
> The argument alignment is wonky after this patch. Could you go over the patch
> and fix that?
I did not think of that, sorry. Fixed now. (It turned out that not all places
were properly aligned even before my patch...)
There are some
omplexities in this PR.
>
> When the functions where marked static, gcc started complaining if they were
> not used, since it consider it dead code. To address this, I had to add or
> fix some `#ifdef`s. Since this code were not actually used unless these
> criteria were fulfilled befo
On Mon, 12 Feb 2024 19:44:46 GMT, Kim Barrett wrote:
>> There are several places in hotspot where an internal function should have
>> been declared static, but isn't.
>>
>> These were discovered by trying to use the gcc option
>> `-Wmissing-declarations` and the corresponding clang option
On Fri, 9 Feb 2024 13:35:55 GMT, Magnus Ihse Bursie wrote:
> This is an attempt to finally implement the idea brought forward in
> JDK-8295729: Properties files is essentially source code. It should have the
> same whitespace checks as all other source code, so we don't get
There are several places in hotspot where an internal function should have been
declared static, but isn't.
These were discovered by trying to use the gcc option `-Wmissing-declarations`
and the corresponding clang option `-Wmissing-prototypes`. These warnings check
that a function either:
a)
> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
> native libraries.
Magnus Ihse Bursie has updated the pull request incrementally with one
additional commit since the last
On Fri, 9 Feb 2024 18:09:11 GMT, Naoto Sato wrote:
>> This is an attempt to finally implement the idea brought forward in
>> JDK-8295729: 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
On Tue, 23 Jan 2024 15:42:55 GMT, Magnus Ihse Bursie wrote:
> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
> native libraries.
This pull request has now been integrated.
On Thu, 8 Feb 2024 14:47:26 GMT, Joachim Kern wrote:
>> And also `#define statvfs statvfs64` is not necessary with the same
>> explanation as for the `opendir` defines above -- sorry again.
>> The very only difference between statvfs and statvfs64 is that the
>> filesystem ID field in statvfs
> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
> native libraries.
Magnus Ihse Bursie has updated the pull request with a new target base due to a
merge or a rebase. The pull re
On Fri, 9 Feb 2024 13:35:55 GMT, Magnus Ihse Bursie wrote:
> This is an attempt to finally implement the idea brought forward in
> JDK-8295729: Properties files is essentially source code. It should have the
> same whitespace checks as all other source code, so we don't get
On Fri, 9 Feb 2024 13:35:55 GMT, Magnus Ihse Bursie wrote:
> This is an attempt to finally implement the idea brought forward in
> JDK-8295729: Properties files is essentially source code. It should have the
> same whitespace checks as all other source code, so we don't get
This is an attempt to finally implement the idea brought forward in
JDK-8295729: 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 or leading tabs instead of spaces.
With Skara
On Thu, 8 Feb 2024 07:44:18 GMT, Magnus Ihse Bursie wrote:
>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
>> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
>> native libraries.
>
> Magnus Ihse Bursie has
On Thu, 8 Feb 2024 09:03:10 GMT, Joachim Kern wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Once more, remove AIX dirent64 et al defines
>
> And also `#define statv
On Tue, 6 Feb 2024 08:05:14 GMT, Matthias Baesken wrote:
>>> I hope finally the AIX part of this PR is done.
>>
>> Thanks for the AIX related effort ; I put it again into our internal
>> build/test queue.
>
>>
>> Thanks for the AIX related effort ; I put it again into our internal
>>
> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
> native libraries.
Magnus Ihse Bursie has updated the pull request incrementally with one
additional commit since the last
On Thu, 1 Feb 2024 11:57:04 GMT, Magnus Ihse Bursie wrote:
> This is a follow-up on
> [JDK-8324053](https://bugs.openjdk.org/browse/JDK-8324053). I have run the
> bin/blessed-modifier-order.sh on the entire code base, and manually checked
> the result. I have reverted all but t
On Thu, 1 Feb 2024 11:57:04 GMT, Magnus Ihse Bursie wrote:
> This is a follow-up on
> [JDK-8324053](https://bugs.openjdk.org/browse/JDK-8324053). I have run the
> bin/blessed-modifier-order.sh on the entire code base, and manually checked
> the result. I have reverted all but t
On Fri, 2 Feb 2024 07:01:33 GMT, Sam James wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Also fix fstatvfs on AIX
>
> make/modules/jdk.hotspot.agent/Lib.gmk line 31:
On Thu, 1 Feb 2024 11:57:04 GMT, Magnus Ihse Bursie wrote:
> This is a follow-up on
> [JDK-8324053](https://bugs.openjdk.org/browse/JDK-8324053). I have run the
> bin/blessed-modifier-order.sh on the entire code base, and manually checked
> the result. I have reverted all but t
On Mon, 5 Feb 2024 14:06:21 GMT, Magnus Ihse Bursie wrote:
>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
>> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
>> native libraries.
>
> Magnus Ihse Bursie has
> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
> native libraries.
Magnus Ihse Bursie has updated the pull request incrementally with one
additional commit since the last
On Fri, 2 Dec 2022 16:42:57 GMT, Magnus Ihse Bursie wrote:
> 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
>
e for each of them. This
> issue is for code I believe belong with the serviceability team.
Magnus Ihse Bursie has updated the pull request incrementally with one
additional commit since the last revision:
Restore period
-
Changes:
- all: https://git.openjdk.org/jdk/pull
On Mon, 5 Feb 2024 19:48:14 GMT, Chris Plummer wrote:
>> src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_ko.properties
>> line 27:
>>
>>> 25:
>>> 26: agent.err.error= 오류
>>> 27: agent.err.exception= 에이전트에 예외사항이 발생했습니다.
>>
>> I
On Tue, 28 Mar 2023 17:36:33 GMT, Chris Plummer wrote:
>> 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)
On Mon, 5 Feb 2024 16:53:54 GMT, Magnus Ihse Bursie wrote:
>> 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 f
e for each of them. This
> issue is for code I believe belong with the serviceability team.
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 three commits:
- Merge branch 'master' into properties-eol-
e for each of them. This
> issue is for code I believe belong with the serviceability team.
Magnus Ihse Bursie has updated the pull request incrementally with one
additional commit since the last revision:
Delete trailing \u0020 as per plummercj's suggestions
-
Changes:
- all
On Tue, 28 Mar 2023 17:36:33 GMT, Chris Plummer wrote:
> What was the reason for not moving forward with this PR?
Me going on medical leave most of 2023... :-/
I intend to get this done now.
-
PR Comment: https://git.openjdk.org/jdk/pull/11490#issuecomment-1927376112
On Fri, 2 Feb 2024 06:55:19 GMT, Magnus Ihse Bursie wrote:
>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
>> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
>> native libraries.
>
> Magnus Ihse Bursie has
> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
> native libraries.
Magnus Ihse Bursie has updated the pull request incrementally with one
additional commit since the last
On Fri, 2 Feb 2024 06:55:19 GMT, Magnus Ihse Bursie wrote:
>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
>> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
>> native libraries.
>
> Magnus Ihse Bursie has
On Fri, 2 Feb 2024 06:55:19 GMT, Magnus Ihse Bursie wrote:
>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
>> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
>> native libraries.
>
> Magnus Ihse Bursie has
On Fri, 2 Feb 2024 06:55:19 GMT, Magnus Ihse Bursie wrote:
>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
>> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
>> native libraries.
>
> Magnus Ihse Bursie has
On Fri, 2 Feb 2024 07:01:33 GMT, Sam James wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add kludge to BufferedRenderPipe.c for AIX
>
> make/modules/jdk.hotspot.agent/Lib
On Fri, 2 Feb 2024 15:48:04 GMT, Magnus Ihse Bursie wrote:
>> src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c line 365:
>>
>>> 363: #else
>>> 364: // Make sure we link to the 64-bit version of the functions
>>> 365: my_openat_f
On Fri, 2 Feb 2024 07:02:43 GMT, Sam James wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add kludge to BufferedRenderPipe.c for AIX
>
> src/java.base/linux/native/libnio/c
On Thu, 1 Feb 2024 15:54:40 GMT, Matthias Baesken wrote:
>>> @MBaesken So my fix in
>>> [25c691d](https://github.com/openjdk/jdk/pull/17538/commits/25c691df823eb9d9db1451637f28d59dd9508386)
>>> did not help? Maybe then it is some other system library that drags in
>>> `fcntl.h`; I assumed it
> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
> native libraries.
Magnus Ihse Bursie has updated the pull request incrementally with one
additional commit since the last revisio
On Thu, 1 Feb 2024 17:21:23 GMT, Joe Darcy wrote:
> I just suggest double-checking on the current maintenance procedures for the
> java.util.concurrent code.
@jddarcy Any idea how to do that? I tried searching for JSR-166 and
java.util.concurrent, but all I could find was talk about a
On Thu, 1 Feb 2024 12:13:08 GMT, Alan Bateman wrote:
> Can you confirm that you've run tier1-4 at least? Some of the library code
> that is changed here is not tested in the lower tiers.
I have run tier1-4 now, and it passes (bar the tests that are currently failing
in mainline). However,
> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
> native libraries.
Magnus Ihse Bursie has updated the pull request with a new target base due to a
merge or a rebase. The pull re
On Thu, 1 Feb 2024 13:47:45 GMT, Matthias Baesken wrote:
>> After adding this additional patch I fully build fastdebug on AIX (hav to
>> admit it does not look very nice).
>>
>>
>> diff --git
>> a/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c
>>
> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
> native libraries.
Magnus Ihse Bursie has updated the pull request incrementally with one
additional commit since the last
This is a follow-up on
[JDK-8324053](https://bugs.openjdk.org/browse/JDK-8324053). I have run the
bin/blessed-modifier-order.sh on the entire code base, and manually checked the
result. I have reverted all but these trivial and uncontroversial changes.
Almost all of these are about moving
On Wed, 31 Jan 2024 09:19:39 GMT, Matthias Baesken wrote:
>> Magnus Ihse Bursie has updated the pull request with a new target base due
>> to a merge or a rebase. The incremental webrev excludes the unrelated
>> changes brought in by the merge/rebase. The pull requ
Over the year, even though we have tried to be diligent, there have been
commits that modify files without updating the copyright year. Here is a mass
update of the copyright years in the build system (`make/**`, `.github/**`).
Feel free to verify that these files have indeed been modified in
On Thu, 23 Nov 2023 11:52:38 GMT, Stefan Karlsson wrote:
>> In the rewrites made for:
>> [JDK-8318757](https://bugs.openjdk.org/browse/JDK-8318757) `VM_ThreadDump
>> asserts in interleaved ObjectMonitor::deflate_monitor calls`
>>
>> I removed the filtering of *owned ObjectMonitors with dead
On Tue, 5 Sep 2023 22:49:41 GMT, Erik Joelsson wrote:
> There are a number of files in the `test` directory that have an incorrect
> copyright header, which includes the "classpath" exception text. This patch
> removes that text from all test files that I could find it in. I did this
> using
On Mon, 6 Mar 2023 20:22:48 GMT, Pavel Rappo wrote:
>> Please review this superficial documentation cleanup that was triggered by
>> unrelated analysis of doc comments in JDK API.
>>
>> The only effect that this multi-area PR has on the JDK API Documentation
>> (i.e. the observable effect on
On Tue, 24 Jan 2023 23:56:23 GMT, Damon Nguyen wrote:
>> Open l10n drop. Files have been updated with translated versions. Whitespace
>> tool has been ran on files.
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional
> commit since the last
On Tue, 17 Jan 2023 11:44:32 GMT, Vladimir Sitnikov
wrote:
>> @RogerRiggs Thanks!
>
> @magicus , have you considered adding `.editorconfig` file (see
> https://editorconfig.org/ ) so it configures developers' editors to trim the
> whitespace?
>
> Of course, `.editorconfig` does not enforce
On Fri, 2 Dec 2022 17:06:23 GMT, Magnus Ihse Bursie wrote:
> [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729) was created in an
> attempt to remove all trailing whitespace from properties files, and enable a
> jcheck verification that they did not come back, similar to oth
On Mon, 16 Jan 2023 17:22:36 GMT, Roger Riggs wrote:
>> 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:
>>
>> - Merge branch 'master' into properties-eol-clean-safe
>&
On Fri, 2 Dec 2022 17:06:23 GMT, Magnus Ihse Bursie wrote:
> [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729) was created in an
> attempt to remove all trailing whitespace from properties files, and enable a
> jcheck verification that they did not come back, similar to oth
ith
> significance. These changes were in turned created by running `find . -type
> f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
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 co
On Wed, 11 Jan 2023 03:30:03 GMT, Archie L. Cobbs wrote:
>> This PR adds a new lint warning category `this-escape`.
>>
>> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to
>> allow the JDK to continue to compile with `-Xlint:all`.
>>
>> A 'this' escape warning is
On Fri, 2 Dec 2022 17:12:55 GMT, Andy Goryachev wrote:
>> This turned out to be much more complicated than anticipated. I am going to
>> close this PR (and bug), and instead I have split up this work in five
>> different bugs:
>>
>> [JDK-8298047](https://bugs.openjdk.org/browse/JDK-8298047)
1 - 100 of 122 matches
Mail list logo
