Remove java.security.manager=allow flag from windows launcher.

[mbien]

this commit implements SM removal step 1 of 3

1. remove SM flag from windows launcher and release new launcher bits
2. move flag to config and switch to new launcher bits
3. implement SM removal for JDK 24 compatibility

extracted from #7928

this changes it only in the windows launcher but keeps it in the bash script. I think we should change it in the linux launcher when we move it into the config and switch to new windows launcher bits in step 2) but not here.

netbeans/platform/o.n.bootstrap/launcher/unix/nbexec

Line 195 in 4c4ed50

jargs_without_clusters="$jargs -Djava.security.manager=allow"

this essentially reverts apache/netbeans-native-launchers@3fea281 although the code is in a different repo now.

[lkishalmi]

Not familiar with the windows native launcher though it looks good to me.

[mbien]

Not familiar with the windows native launcher though it looks good to me.

me neither. I have to check the past PRs and take a look what needs to be done before a release. Probably a version bump somewhere too. Then actually test it on windows.

[neilcsmith-net]

@mbien well, it should be testable from https://github.com/apache/netbeans/actions/runs/12091765448

Will need a version update before attempting to move to vote, in manner outlined at #6869 (comment)

There are a couple of other changes that would be nice to get in to the launcher if we're going for an update, but something to discuss elsewhere ...

[neilcsmith-net]

@mbien check b8e969a which has all the places this needs setting.

Please use 101.2.0.0 - unless there's a particular reason not to? Build ID wrapping, possibly? At least, the idea was to use strictly increment numbers and not suggest semantic versioning in any way.

Please do the version change in a separate commit this time - I failed to do that, but should have in hindsight.

[mbien]

the launcher build started failing recently.

 jvmlauncher.cpp: In member function ‘bool JvmLauncher::startInProcJvm(const char*, const std::__cxx11::list<std::__cxx11::basic_string<char> >&, const std::__cxx11::list<std::__cxx11::basic_string<char> >&)::Jvm::init(const std::__cxx11::list<std::__cxx11::basic_string<char> >&)’:
jvmlauncher.cpp:252:61: error: ordered comparison of pointer with integer zero (‘HMODULE’ {aka ‘HINSTANCE__*’} and ‘int’)
  252 |                 if (option.find("-splash:") == 0 && hSplash > 0) {
      |                                                     ~~~~~~~~^~~
make: *** [Makefile.mingw:34: nbexec64.dll] Error 1

Probably due to the ubuntu image update. I take a look if i can fix the pointer comparison.

[mbien]

i tested this with the following setup:

• win 10 via virtualbox
• jdk 24 build 28
• NB dev build taken from freshly rebased Remove SecurityManager layer #7928 (ci build)
• launcher binaries from this PR (ci build)

and it seems to work fine:

-------------------------------------------------------------------------------
>Log Session: Sunday, December 15, 2024, 5:22:23 PM Greenwich Mean Time
>System Info: 
 Product Version         = Apache NetBeans IDE DEV (Build dev-3687560331e398c3854f24675c36c44c48dcb804)
 Operating System        = Windows 10 version 10.0 running on amd64
 Java; VM; Vendor        = 24-ea; OpenJDK 64-Bit Server VM 24-ea+28-3562; Oracle Corporation
 Runtime                 = OpenJDK Runtime Environment 24-ea+28-3562
 Java Home               = C:\Users\virtual10\Downloads\openjdk-24-ea+28_windows-x64_bin\jdk-24

[neilcsmith-net]

The need to adapt to the compiler on the newer CI image concerns me. I think we should pin all the native build workflows to the lowest supported image for broadest compatibility, before moving to further releases of any. Ideally we'd disconnect the runner OS from the compiler and library versions.

[mbien]

The need to adapt to the compiler on the newer CI image concerns me.

the NULL comparison change is something which should be done in any case. Comparing a pointer using > with 0 seems to be error prone - a warning might have switched to an error.

[neilcsmith-net]

The change itself is fine, the need to change, which shows that the build environment we're using for the distributed natives has changed, is what concerns me.

[mbien]

rebased on top of #8062 which locks binaries build to ubuntu 22