On Thu, 3 Apr 2025 14:09:58 GMT, Alan Bateman wrote:
> Right now, the static-jdk image is a bit strange in that it's a modular
> run-time image but with all native code compiled into bin/java. In time we
> hope that jlink will be able to create a static image where everything is in
> the singl
On Thu, 3 Apr 2025 14:24:18 GMT, Magnus Ihse Bursie wrote:
> So while we continue to hammer out how to improve this, I think it is
> important to be able to test static builds in mainline, or they will break.
Agree with @magicus on the importance of being able to test static builds in
mainlin
On Tue, 13 May 2025 21:28:00 GMT, Jiangli Zhou wrote:
> Please review this PR for skipping
> jdk/test/lib/process/TestNativeProcessBuilder on static-jdk. Duplicating the
> context from https://bugs.openjdk.org/browse/JDK-8356904 description:
>
> jdk/t
On Wed, 21 May 2025 18:46:25 GMT, Roger Riggs wrote:
>> Jiangli Zhou has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update copyright year in
>> test/lib-test/jdk/test/lib/process/TestNativeProcessBuild
On Wed, 14 May 2025 15:44:08 GMT, Jiangli Zhou wrote:
>> Please review this PR for skipping
>> jdk/test/lib/process/TestNativeProcessBuilder on static-jdk. Duplicating the
>> context from https://bugs.openjdk.org/browse/JDK-8356904 description:
>>
On Tue, 20 May 2025 00:49:28 GMT, Henry Jen wrote:
>> Jiangli Zhou has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update copyright year in
>> test/lib-test/jdk/test/lib/process/TestNativeProcessBuilder.j
On Thu, 15 May 2025 17:15:20 GMT, Jiangli Zhou wrote:
>> test/lib-test/TEST.ROOT line 31:
>>
>>> 29: keys=randomness
>>> 30:
>>> 31: # Minimum jtreg version
>>
>> Shoule we update the copyright year for file TestNativeProcessBuilder.jav
On Wed, 14 May 2025 13:21:37 GMT, SendaoYan wrote:
>> Jiangli Zhou has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update copyright year in
>> test/lib-test/jdk/test/lib/process/TestNativeProcessB
On Wed, 14 May 2025 13:21:37 GMT, SendaoYan wrote:
>> Jiangli Zhou has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update copyright year in
>> test/lib-test/jdk/test/lib/process/TestNativeProcessB
, we decided to
> skip the affected hotspot tier1 tests on static-jdk. We should skip
> jdk/test/lib/process/TestNativeProcessBuilder.java on static-jdk as well.
> [JDK-8352305](https://bugs.openjdk.org/browse/JDK-8352305) will add tests
> using custom launcher executable on static
Please review this PR for skipping
jdk/test/lib/process/TestNativeProcessBuilder on static-jdk. Duplicating the
context from https://bugs.openjdk.org/browse/JDK-8356904 description:
jdk/test/lib/process/TestNativeProcessBuilder.java (in lib-test/tier1) uses a
native test launcher executable, ex
On Tue, 6 May 2025 17:47:04 GMT, Magnus Ihse Bursie wrote:
>> Jiangli Zhou has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Problemlist jdk/test/lib/hprof/HprofTest.
>
> Marked as reviewed by ihse (Re
On Fri, 2 May 2025 01:15:05 GMT, Jiangli Zhou wrote:
> Please review this PR to problemlist jdk & langtools tier1 tests requiring
> runtime usages of /bin/tools, for testing on static-jdk. The affected
> tests using following tools at runtime:
>
> - javac
> - javadoc
; - jps
>
> The latest teir1 testing results on static-jdk:
> https://github.com/jianglizhou/jdk/actions/runs/14781658116/job/41503569932.
Jiangli Zhou has updated the pull request incrementally with one additional
commit since the last revision:
Problemlist jdk/test/lib/hprof/Hpro
Please review this PR to problemlist jdk & langtools tier1 tests requiring
runtime usages of /bin/tools, for testing on static-jdk. The affected
tests using following tools at runtime:
- javac
- javadoc
- jar
- jarsigner
- jimage
- jps
-
Commit messages:
- Merge branch 'openjdk:ma
On Tue, 29 Apr 2025 06:43:59 GMT, Magnus Ihse Bursie wrote:
>> Jiangli Zhou has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Merge branch 'JDK-8355080' of ssh://github.com/jianglizhou/jdk into
>
On Mon, 28 Apr 2025 08:30:43 GMT, Maurizio Cimadamore
wrote:
>> Jiangli Zhou has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Merge branch 'JDK-8355080' of ssh://github.com/jianglizhou/jdk into
>
On Tue, 22 Apr 2025 21:08:56 GMT, Jiangli Zhou wrote:
> Please review this PR that changes to use `NativeLibraries.loadLibrary()` for
> loading the `libsyslookup` in `jdk.internal.foreign.SystemLookup` class.
>
> `NativeLibraries.loadLibrary()` handles both the shared library
On Mon, 28 Apr 2025 13:04:57 GMT, Jorn Vernee wrote:
> > Having to upgrade to JNI is a bit sad -- although I get that it is required
> > as a workaround for now. For the longer term I'd prefer a better way to
> > integrate static lookups in the FFM API. For instance, all
> > `JNI::loadLibrary`
On Fri, 25 Apr 2025 11:31:50 GMT, Jaikiran Pai wrote:
> Hello Jiangli, if I understand this change correctly, then this is forcing a
> non-JNI library to be a JNI library for it to work on static JDK. Is that a
> requirement for static JDK builds? Or is it just a convenient way to use
> existi
On Thu, 24 Apr 2025 15:14:27 GMT, Henry Jen wrote:
>> Jiangli Zhou has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Merge branch 'JDK-8355080' of ssh://github.com/jianglizhou/jdk into
>> JDK
On Tue, 22 Apr 2025 21:32:48 GMT, Chen Liang wrote:
>> Jiangli Zhou has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Merge branch 'JDK-8355080' of ssh://github.com/jianglizhou/jdk into
>> JDK
On Wed, 16 Apr 2025 23:41:40 GMT, Jiangli Zhou wrote:
> Please review this simple test change that skips the test case loading using
> JDK `libzip.so` on static JDK in
> test/jdk/jdk/internal/loader/NativeLibraries/Main.java. AFAICT, the test case
> using `NativeLibrariesT
On Wed, 23 Apr 2025 01:11:24 GMT, Jaikiran Pai wrote:
>>> Hello Jiangli, can you add a few more details to the linked JBS issue? If I
>>> understand this change correctly, then what's being proposed in this PR
>>> seems to indicate that the `jdk.internal.loader.RawNativeLibraries` is
>>> unabl
On Wed, 23 Apr 2025 00:24:55 GMT, Henry Jen wrote:
> Do we need this include? DEF_STATIC_JNI_OnLoad is defined by jni_util.h,
> which should include jni.h?
Removed, thanks!
-
PR Review Comment: https://git.openjdk.org/jdk/pull/24801#discussion_r2055090726
gt; In addition to GHA testing, I tested the change on static-jdk with jdk tier1
> tests on linux-x64 locally. All java/foreign/* jdk tier1 tests pass with the
> change. Without the change, there are about 60 java/foreign/* jdk tier1 tests
> fail on static-jdk.
Jiangli Zhou has updat
On Tue, 22 Apr 2025 21:32:48 GMT, Chen Liang wrote:
> `sysLookup` does look much cleaner compared to `jdkLibraryPath`.
@liach Thanks for the quick review!
-
PR Comment: https://git.openjdk.org/jdk/pull/24801#issuecomment-2822696068
gt; In addition to GHA testing, I tested the change on static-jdk with jdk tier1
> tests on linux-x64 locally. All java/foreign/* jdk tier1 tests pass with the
> change. Without the change, there are about 60 java/foreign/* jdk tier1 tests
> fail on static-jdk.
Jiangli Zhou has updat
Please review this PR that changes to use `NativeLibraries.loadLibrary()` for
loading the `libsyslookup` in `jdk.internal.foreign.SystemLookup` class.
`NativeLibraries.loadLibrary()` handles both the shared library and (static)
built-in library loading properly. On `static-jdk`, calling
`Native
On Tue, 22 Apr 2025 07:37:45 GMT, Jaikiran Pai wrote:
> Hello Jiangli, can you add a few more details to the linked JBS issue? If I
> understand this change correctly, then what's being proposed in this PR seems
> to indicate that the `jdk.internal.loader.RawNativeLibraries` is unable to
> loa
On Sun, 20 Apr 2025 03:42:32 GMT, SendaoYan wrote:
>> Please review this simple test change that skips the test case loading using
>> JDK `libzip.so` on static JDK in
>> test/jdk/jdk/internal/loader/NativeLibraries/Main.java. AFAICT, the test
>> case using `NativeLibrariesTest.LIB_NAME` (`libn
Please review this simple test change that skips the test case loading using
JDK `libzip.so` on static JDK in
test/jdk/jdk/internal/loader/NativeLibraries/Main.java. AFAICT, the test case
using `NativeLibrariesTest.LIB_NAME` (`libnativeLibrariesTest.so`) can provide
coverage on static JDK.
Tha
On Sat, 22 Mar 2025 03:46:38 GMT, Jiangli Zhou wrote:
> Please review following changes, thanks.
>
> - Add `static` to the vm_info for static JDK. The `-version` output now
> contains `static` on static JDK, e.g.:
>
>
> $ static-jdk/bin/java -version
> openjdk versi
On Tue, 18 Mar 2025 18:57:04 GMT, Jiangli Zhou wrote:
> Please review this PR that adds `@requires !jdk.static` to tests, thanks.
>
> - runtime/StackGap/TestStackGap.java
> - runtime/StackGuardPages/TestStackGuardPages.java
> - runtime/TLS/TestTLS.java
> - runtime
On Wed, 26 Mar 2025 19:28:24 GMT, Jiangli Zhou wrote:
>> Please review following changes, thanks.
>>
>> - Add `static` to the vm_info for static JDK. The `-version` output now
>> contains `static` on static JDK, e.g.:
>>
>>
>> $ static-jdk/bin/jav
On Wed, 26 Mar 2025 17:47:46 GMT, Aleksey Shipilev wrote:
> Looks basically fine, just nits:
Thanks for reviewing, @shipilev!
Please help re-approve after update.
> test/hotspot/jtreg/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOptionsUtils.java
> line 56:
>
>> 54:
>>
On Wed, 26 Mar 2025 17:46:55 GMT, Aleksey Shipilev wrote:
>> Jiangli Zhou has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Address @dholmes-ora's comment: Use `strlen` to get the length for ",
>>
ib.Platform.isStatic()`, which checks for `static` in
> `java.vm.info` system property to determine if current test is running on
> static JDK.
> - Change `CommandLineOptionTest` to only call `getVMTypeOption()` on regular
> JDK (`!Platform.isStatic()`).
> - Change `optionsvalidati
On Wed, 26 Mar 2025 06:02:42 GMT, David Holmes wrote:
>> Jiangli Zhou has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Address @dholmes-ora's comment: Use `strlen` to get the length for ",
>> sta
ib.Platform.isStatic()`, which checks for `static` in
> `java.vm.info` system property to determine if current test is running on
> static JDK.
> - Change `CommandLineOptionTest` to only call `getVMTypeOption()` on regular
> JDK (`!Platform.isStatic()`).
> - Change `optionsvalidati
On Tue, 25 Mar 2025 05:16:36 GMT, David Holmes wrote:
>> Jiangli Zhou has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Allocate memory for vm_info string using NEW_C_HEAP_ARRAY.
>
> src/hotspot/share/runtim
On Mon, 24 Mar 2025 07:02:33 GMT, David Holmes wrote:
> The way we construct the VM info string is rather clunky and does not scale
> when you want to add more information like this.
Agree.
> Short of rewriting it to dynamically create the final string from its
> constituent parts, couldn't
ib.Platform.isStatic()`, which checks for `static` in
> `java.vm.info` system property to determine if current test is running on
> static JDK.
> - Change `CommandLineOptionTest` to only call `getVMTypeOption()` on regular
> JDK (`!Platform.isStatic()`).
> - Change `optionsvalidati
Please review following changes, thanks.
- Add `static` to the vm_info for static JDK. The `-version` output now
contains `static` on static JDK, e.g.:
$ static-jdk/bin/java -version
openjdk version "25-internal" 2025-09-16
OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.jiangliz
On Wed, 19 Mar 2025 00:29:49 GMT, David Holmes wrote:
>> Please review this PR that adds `@requires !jdk.static` to tests, thanks.
>>
>> - runtime/StackGap/TestStackGap.java
>> - runtime/StackGuardPages/TestStackGuardPages.java
>> - runtime/TLS/TestTLS.java
>> - runtime/jni/daemonDestroy/TestDae
On Wed, 19 Mar 2025 09:20:33 GMT, Alan Bateman wrote:
> can't rule anything in or out right now
+1
@AlanBateman @dholmes-ora Does it look reasonable to not run these tests on
static JDK for now?
-
PR Comment: https://git.openjdk.org/jdk/pull/24103#issuecomment-2738148828
On Tue, 18 Mar 2025 18:57:04 GMT, Jiangli Zhou wrote:
> Please review this PR that adds `@requires !jdk.static` to tests, thanks.
>
> - runtime/StackGap/TestStackGap.java
> - runtime/StackGuardPages/TestStackGuardPages.java
> - runtime/TLS/TestTLS.java
> - runtime
On Wed, 19 Mar 2025 00:29:49 GMT, David Holmes wrote:
> @jianglizhou shouldn't these native executables be built differently to work
> with the static JDK? Otherwise how does a user create a native executable
> that launches the JVM?
I think it's the case of using customized launcher and we ne
Please review this PR that adds `@requires !jdk.static` to tests, thanks.
- runtime/StackGap/TestStackGap.java
- runtime/StackGuardPages/TestStackGuardPages.java
- runtime/TLS/TestTLS.java
- runtime/jni/daemonDestroy/TestDaemonDestroy.java
- runtime/jni/getCreatedJavaVMs/TestGetCreatedJavaVMs.java
On Fri, 14 Feb 2025 18:31:52 GMT, Jiangli Zhou wrote:
> Please review the fix to make
> `java/lang/String/nativeEncoding/StringPlatformChars.java` jtreg test:
>
> - Lookup `JNU_GetStringPlatformChars`, `JNU_ClassString` and
> `JNU_NewStringPlatform` dynamically
>
ibstringPlatformChars.so`
> with `libjava.so`
> - Link with `-ldl` explicitly
>
> The test passed on Linux, macos and Windows in GHA testing,
> https://github.com/jianglizhou/jdk/actions/runs/13320840902/job/37206171224
Jiangli Zhou has updated the pull request incrementally wit
On Fri, 21 Feb 2025 06:57:05 GMT, Alan Bateman wrote:
> > Updated to skipping
> > `java/lang/String/nativeEncoding/StringPlatformChars.java` on static JDK.
>
> Thanks. If you can bump the copyright header date then I think we are done
> with this one.
Done, thanks!
-
PR Comment:
On Fri, 14 Feb 2025 18:31:52 GMT, Jiangli Zhou wrote:
> Please review the fix to make
> `java/lang/String/nativeEncoding/StringPlatformChars.java` jtreg test:
>
> - Lookup `JNU_GetStringPlatformChars`, `JNU_ClassString` and
> `JNU_NewStringPlatform` dynamically
>
ibstringPlatformChars.so`
> with `libjava.so`
> - Link with `-ldl` explicitly
>
> The test passed on Linux, macos and Windows in GHA testing,
> https://github.com/jianglizhou/jdk/actions/runs/13320840902/job/37206171224
Jiangli Zhou has updated the pull request with a new target b
On Tue, 18 Feb 2025 19:29:10 GMT, Jiangli Zhou wrote:
>> Please review this change that adds the `jdk.static` VMProps. It can be used
>> to skip tests not for running on static JDK.
>>
>> This also adds a new WhiteBox native method,
>> `jdk.test.whitebox.WhiteBox
On Fri, 7 Feb 2025 23:51:41 GMT, Jiangli Zhou wrote:
> Please review this change that adds the `jdk.static` VMProps. It can be used
> to skip tests not for running on static JDK.
>
> This also adds a new WhiteBox native method,
> `jdk.test.whitebox.WhiteBox.isStatic()`, w
On Wed, 19 Feb 2025 07:33:02 GMT, Alan Bateman wrote:
> > This part however feels odd. Updating this (and other tests in future) to
> > use the `@requires !jdk.static` to identify the presence or absence of a
> > specific tool in the JDK installation doesn't seem right. Perhaps they
> > should
On Wed, 19 Feb 2025 06:54:50 GMT, Jaikiran Pai wrote:
> On a more general note, is it a goal to have the static JDK build run against
> all these tests that are part of the JDK repo? Would that mean that a lot of
> these will have to start using `@requires` to accomodate this?
Running static J
On Wed, 19 Feb 2025 06:54:50 GMT, Jaikiran Pai wrote:
>> Jiangli Zhou 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.
>
> On a more general note,
On Wed, 19 Feb 2025 00:06:52 GMT, Man Cao wrote:
>> Jiangli Zhou 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 request contains two addi
On Tue, 18 Feb 2025 17:05:06 GMT, Alan Bateman wrote:
> I don't object to changing this test but it might be simpler to just skip
> this test, once we can use `@requires !jdk.static`.
Thanks, @AlanBateman. I think skipping this test for static JDK sounds
reasonable to me, since this test seems
On Tue, 18 Feb 2025 19:29:10 GMT, Jiangli Zhou wrote:
>> Please review this change that adds the `jdk.static` VMProps. It can be used
>> to skip tests not for running on static JDK.
>>
>> This also adds a new WhiteBox native method,
>> `jdk.test.whitebox.WhiteBox
are not
> modified by the current PR to skip running on static JDK. Those can be done
> after the current change is fully discussed and reviewed/approved.
Jiangli Zhou has updated the pull request with a new target base due to a merge
or a rebase. The pull request now contains one commit:
On Tue, 11 Feb 2025 08:10:24 GMT, Alan Bateman wrote:
>> I think this looks okay, I'm just wondering is one property is enough to
>> cover all the configurations.
>
>> Thanks, @AlanBateman.
>>
>> > I'm just wondering is one property is enough to cover all the
>> > configurations.
>>
>> +1
>>
are not
> modified by the current PR to skip running on static JDK. Those can be done
> after the current change is fully discussed and reviewed/approved.
Jiangli Zhou has updated the pull request with a new target base due to a merge
or a rebase. The incremental webrev excludes the unrel
Please review the fix to make
`java/lang/String/nativeEncoding/StringPlatformChars.java` jtreg test:
- Lookup `JNU_GetStringPlatformChars`, `JNU_ClassString` and
`JNU_NewStringPlatform` dynamically
- Remove `#include "jni_util.h"` and don't link `libstringPlatformChars.so`
with `libjava.so`
-
On Tue, 11 Feb 2025 08:10:24 GMT, Alan Bateman wrote:
> That's okay with me. I'm hoping Magnus will jump in when he gets a chance as
> he has experience with the "other" static build configurations.
@magicus Any thoughts and input on this?
-
PR Comment: https://git.openjdk.org/jdk
On Mon, 10 Feb 2025 08:21:21 GMT, Alan Bateman wrote:
>> Please review this change that adds the `jdk.static` VMProps. It can be used
>> to skip tests not for running on static JDK.
>>
>> This also adds a new WhiteBox native method,
>> `jdk.test.whitebox.WhiteBox.isStatic()`, which is used by
On Thu, 6 Feb 2025 20:14:36 GMT, Jiangli Zhou wrote:
> This is similar to https://github.com/openjdk/jdk/pull/23431 change. It
> removes libjvm.so as a recorded dependency for libExplicitAttach.so by not
> explicitly link libExplicitAttach.so with libjvm.so at build time. To do
&
On Mon, 10 Feb 2025 04:00:44 GMT, Jiangli Zhou wrote:
>> This is similar to https://github.com/openjdk/jdk/pull/23431 change. It
>> removes libjvm.so as a recorded dependency for libExplicitAttach.so by not
>> explicitly link libExplicitAttach.so with libjvm.so at build ti
pull/23431 comment
> thread among @dholmes-ora, @AlanBateman and myself. Based on my
> understanding, we are converging on the approach to fix just these few tests,
> and both @dholmes-ora and @AlanBateman are okay with that. So I'm sending out
> this PR for libExplicitAttach's
On Mon, 10 Feb 2025 07:26:00 GMT, Alan Bateman wrote:
> Can you bump the copyright header date on libExplicitAttach.c before you
> integrate.
Done.
@AlanBateman @dholmes-ora Thanks for the review!
-
PR Comment: https://git.openjdk.org/jdk/pull/23500#issuecomment-2648775523
pull/23431 comment
> thread among @dholmes-ora, @AlanBateman and myself. Based on my
> understanding, we are converging on the approach to fix just these few tests,
> and both @dholmes-ora and @AlanBateman are okay with that. So I'm sending out
> this PR for libExplicitAttach's
On Sat, 8 Feb 2025 09:29:48 GMT, Alan Bateman wrote:
> Is the JavaVM param passed to JNI_OnLoad usable in static builds? If so then
> this just needs to be saved, no need to use GetCreatedJavaVMs, right?
Yes, on static JDK, `JNI_OnLoad`'s `JavaVM *` argument behaves the same as on
regular JDK.
Please review this change that adds the `jdk.static` VMProps. It can be used to
skip tests not for running on static JDK.
This also adds a new WhiteBox native method,
`jdk.test.whitebox.WhiteBox.isStatic()`, which is used by VMProps to determine
if it's static at runtime.
`@requires !jdk.stat
On Fri, 7 Feb 2025 10:38:37 GMT, Alan Bateman wrote:
> Can you look at adding native init method instead? This could be called from
> the System.loadLibraray and avoid introduce a side effect of startThreads
> initialising GetCreatedJavaVMs.
Done, thanks. Moved `JNI_GetCreatedJavaVMs` lookup i
pull/23431 comment
> thread among @dholmes-ora, @AlanBateman and myself. Based on my
> understanding, we are converging on the approach to fix just these few tests,
> and both @dholmes-ora and @AlanBateman are okay with that. So I'm sending out
> this PR for libExplicitAttach's
This is similar to https://github.com/openjdk/jdk/pull/23431 change. It removes
libjvm.so as a recorded dependency for libExplicitAttach.so by not explicitly
link libExplicitAttach.so with libjvm.so at build time. To do that, it also
changes libExplicitAttach.c to dynamically lookup the JNI_GetC
On Tue, 28 Jan 2025 22:42:00 GMT, Alexey Semenyuk wrote:
> Reapply [JDK-8348348](https://bugs.openjdk.org/browse/JDK-8348348)
Marked as reviewed by jiangli (Reviewer).
Looks good.
@alexeysemenyukoracle, Is the actual change addressing the compilation issue in
closed repo? If so, is it to prop
On Tue, 28 Jan 2025 20:07:17 GMT, Kevin Rushforth wrote:
> A Mach5 job I submitted passed
@kevinrushforth Thanks!
-
PR Comment: https://git.openjdk.org/jdk/pull/23340#issuecomment-2619970106
On Tue, 28 Jan 2025 19:22:52 GMT, Jiangli Zhou wrote:
> Please review this workaround for the compiler error on Windows. This error
> occurs in closed build with custom make logic that uses zip_util.c. The error
> indicates `DEF_STATIC_JNI_OnLoad` is not defined, thus disable the
On Tue, 28 Jan 2025 19:22:52 GMT, Jiangli Zhou wrote:
> Please review this workaround for the compiler error on Windows. This error
> occurs in closed build with custom make logic that uses zip_util.c. The error
> indicates `DEF_STATIC_JNI_OnLoad` is not defined, thus disable the
On Tue, 28 Jan 2025 20:08:54 GMT, Alexey Semenyuk wrote:
> I believe it complained about the way DEF_STATIC_JNI_OnLoad is defined. That
> is why disabling the usage of DEF_STATIC_JNI_OnLoad fixes the problem.
That probably describes the issue more clear. Thumbs up.
-
PR Comment: h
On Tue, 28 Jan 2025 19:22:52 GMT, Jiangli Zhou wrote:
> Please review this workaround for the compiler error on Windows. This error
> occurs in closed build with custom make logic that uses zip_util.c. The error
> indicates `DEF_STATIC_JNI_OnLoad` is not defined, thus disable the
Please review this workaround for the compiler error on Windows. This error
occurs in closed build with custom make logic that uses zip_util.c. The error
indicates `DEF_STATIC_JNI_OnLoad` is not defined, thus disable the macro on
Windows for now until the cause is fully understood.
[2025-01-28
On Thu, 23 Jan 2025 02:11:29 GMT, Jiangli Zhou wrote:
> Please review this trivial cleanup that removes the #ifdef STATIC_BUILD
> around DEF_STATIC_JNI_OnLoad from zip_util.c. Thanks.
This pull request has now been integrated.
Changeset: 81032560
Author:Jiangli Zhou
URL:
On Tue, 28 Jan 2025 16:24:57 GMT, Severin Gehwolf wrote:
>> Please review this trivial cleanup that removes the #ifdef STATIC_BUILD
>> around DEF_STATIC_JNI_OnLoad from zip_util.c. Thanks.
>
> Looks good. `DEF_STATIC_JNI_OnLoad` will do the right thing based on the
> `STATIC_BUILD` define here:
On Thu, 23 Jan 2025 02:11:29 GMT, Jiangli Zhou wrote:
> Please review this trivial cleanup that removes the #ifdef STATIC_BUILD
> around DEF_STATIC_JNI_OnLoad from zip_util.c. Thanks.
I would appreciate if anyone can help take a look of this, thanks.
-
PR Comment:
Please review this trivial cleanup that removes the #ifdef STATIC_BUILD around
DEF_STATIC_JNI_OnLoad from zip_util.c. Thanks.
-
Commit messages:
- 8348348: Remove unnecessary #ifdef STATIC_BUILD around DEF_STATIC_JNI_OnLoad
from zip_util.c
Changes: https://git.openjdk.org/jdk/pull
On Mon, 2 Dec 2024 15:12:24 GMT, Magnus Ihse Bursie wrote:
>> Hotspot changes look fine.
>>
>> Thanks
>
> @dholmes-ora @coleenp @erikj79 Thanks for your reviews!
@magicus Thanks for integrating the changes, particularly reworking and making
the statically linked launcher build changes cleaner!
On Wed, 13 Nov 2024 01:40:23 GMT, Jiangli Zhou wrote:
>> @jianglizhou Thank you for your assistance in figuring out the problem. I
>> guess I throw out too much code from the hermetic-java-runtime branch when
>> trying to minimize the changes to only build-related stuff. The
On Mon, 4 Nov 2024 21:30:10 GMT, Magnus Ihse Bursie wrote:
>>> I can confirm that with your patch, and clang, and a complete wipe +
>>> rebuild, the .java file loading works. I'm currently testing with gcc as
>>> well.
>>
>> Good.
>>
>> I tested using gcc.
>
> @jianglizhou Thank you for your
On Mon, 4 Nov 2024 21:24:54 GMT, Magnus Ihse Bursie wrote:
> > There is no `static-jdk/bin/java.debuginfo`. I do see there's a
> > `./support/static-native/launcher/java.debuginfo`.
>
> Ah, I missed that part. So it's just about copying it to the right place?
> Fine, that is trivial to add. Di
On Mon, 4 Nov 2024 21:12:31 GMT, Magnus Ihse Bursie wrote:
> I can confirm that with your patch, and clang, and a complete wipe + rebuild,
> the .java file loading works. I'm currently testing with gcc as well.
Good.
I tested using gcc.
-
PR Comment: https://git.openjdk.org/jdk/
On Fri, 1 Nov 2024 16:25:59 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
>> dynamica
On Sun, 3 Nov 2024 20:23:32 GMT, Jiangli Zhou 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 10 commits:
>>
>> - Merge branch 'master' into static-jdk-image
On Fri, 1 Nov 2024 16:25:59 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
>> dynamica
On Sat, 2 Nov 2024 01:05:27 GMT, Jiangli Zhou wrote:
> > > I finally noticed that you are testing a precompiled HelloWorld class,
> > > and I have been running with a source file argument to have java compile
> > > it on the fly.
> > > When I try using a pre
On Fri, 1 Nov 2024 22:24:28 GMT, Jiangli Zhou wrote:
> > I finally noticed that you are testing a precompiled HelloWorld class, and
> > I have been running with a source file argument to have java compile it on
> > the fly.
> > When I try using a pre-compiled HelloWor
On Fri, 1 Nov 2024 16:09:20 GMT, Magnus Ihse Bursie wrote:
> I finally noticed that you are testing a precompiled HelloWorld class, and I
> have been running with a source file argument to have java compile it on the
> fly.
>
> When I try using a pre-compiled HelloWorld, the linux port works f
1 - 100 of 261 matches
Mail list logo
