I don't fully understand all the steps related to this procedure but when I
used RELEASE250 in my platform apps I noticed the error message below when
exiting the program.
As it turns out it's there for NetBeans 25 also when started with
netbeans -J-Dnetbeans.logger.console=true

FINE [java.lang.Runtime]: Runtime.exit() called with status: 0
java.lang.Throwable: Runtime.exit(0)
[catch] at java.base/java.lang.Shutdown.logRuntimeExit(Shutdown.java:179)
       at java.base/java.lang.Shutdown.exit(Shutdown.java:160)
       at java.base/java.lang.Runtime.exit(Runtime.java:188)
       at java.base/java.lang.System.exit(System.java:1923)
       at org.netbeans.TopSecurityManager.exit(TopSecurityManager.java:189)
       at org.netbeans.core.NbLifeExit.run(NbLifeExit.java:99)
       at org.openide.util.Task.run(Task.java:233)
       at
org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1403)
       at
org.netbeans.modules.openide.util.GlobalLookup.execute(GlobalLookup.java:45)
       at org.openide.util.lookup.Lookups.executeWith(Lookups.java:287)
       at
org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2018)



Is this ok?

Den tors 20 feb. 2025 kl 19:55 skrev Michael Bien <mbie...@gmail.com>:

> Going through the threads, consensus seems to be to go ahead with the
> change.
>
> I rebased on top of the spec bump PR - please review since it would be
> good to integrate it for NB26 asap.
>
> The same PR does also allow CI to start testing on JDK 24 - which we would
> be doing at this point already. (this was delayed by the decision of
> releasing NB 25 with ||-DTopSecurityManager.disable=true, #8169)
>
> -mbien
>
>
> On 14.01.25 18:12, Michael Bien wrote:
> > another update: the freshly released windows launcher is now also
> integrated, which means that dev-builds from
> >
> > https://github.com/apache/netbeans/pull/7928
> >
> > should now work on all supported platforms (and JDK version range 17-24).
> >
> > -mbien
> >
> >
> > On 06.01.25 19:36, Michael Bien wrote:
> >> quick update: PR is rebased, tests are green on JDK 24. Devbuild is
> also testable on linux/mac for the interested. (for windows manual,
> launcher copying required)
> >>
> >> -mbien
> >>
> >>
> >> On 19.12.24 00:08, Michael Bien wrote:
> >>> with Jan's nb-javac update PR (#8037) we now have all ingredients to
> run all java tests on JDK 24-ea (chicken-egg problem).
> >>>
> >>> I temporarily merged both PRs with all tests enabled and it passed.
> >>> https://github.com/apache/netbeans/pull/7928#issuecomment-2552419685
> >>> (will remove the commit again once #8037 is merged)
> >>>
> >>> best regards,
> >>>
> >>> mbien
> >>>
> >>> On 30.11.24 01:28, Laszlo Kishalmi wrote:
> >>>> Well, I also like the agent proposal, and already bookmarked it as an
> example if I ever need something like that.
> >>>>
> >>>> Though, I agree with Michael, simplicity rules, let's get the SM code
> removed.
> >>>>
> >>>> On 11/29/24 15:23, Michael Bien wrote:
> >>>>> Hello,
> >>>>>
> >>>>> this thread discusses _how_ step 3) should be implemented
> >>>>>
> >>>>>  1) remove SM flag from launcher and release new launcher bits
> >>>>>  2) move flag to start config and switch to new launcher bits
> >>>>>  3) implement SM removal for JDK 24 compatibility
> >>>>>
> >>>>> we have two proposals
> >>>>>
> >>>>> https://github.com/apache/netbeans/pull/3386 (reimplement parts
> using a new JVM agent layer)
> >>>>>
> >>>>> https://github.com/apache/netbeans/pull/7928 (remove SM layer
> entirely)
> >>>>>
> >>>>>
> >>>>> I won't paste the PR texts here since this would make this mail very
> long, but please read through both PRs and make sure you are also up to
> date on JEP 486.
> >>>>>
> >>>>> What I will note though is that I am running NetBeans since version
> 23 with SM disabled and didn't experience any issues so far or even can
> tell a difference. (I believe Neil did also test it at some point after
> discussions on apache slack).
> >>>>>
> >>>>> I will also always push for the solution which makes maintenance
> easier over the long term - this typically is the less complex solution. So
> even though I do _like_ the agent proposal from a technical perspective
> since it shows how powerful JVM agents can be, I don't think we should add
> this additional layer to everything and maintain a custom bytecode
> interceptor/transformer too. (for why I believe that we can likely get rid
> of the SM layer without a replacement, please read the PR text)
> >>>>>
> >>>>> best regards,
> >>>>>
> >>>>> michael
> >>>>>
> >>>>>
> >>>>> https://openjdk.org/jeps/486
> >>>>>
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
> >>>>> For additional commands, e-mail: dev-h...@netbeans.apache.org
> >>>>>
> >>>>> For further information about the NetBeans mailing lists, visit:
> >>>>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
> >>>> For additional commands, e-mail: dev-h...@netbeans.apache.org
> >>>>
> >>>> For further information about the NetBeans mailing lists, visit:
> >>>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
> >>>>
> >>>>
> >>>>
> >>>
> >>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
> For additional commands, e-mail: dev-h...@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>

Reply via email to