You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@netbeans.apache.org by Michael Bien <mb...@gmail.com> on 2024/12/18 23:08:38 UTC
Re: [DISCUSS] Security Manager removal implementation
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-unsubscribe@netbeans.apache.org
>> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS] Security Manager removal implementation
Posted by Neil C Smith <ne...@apache.org>.
On Fri, 21 Feb 2025 at 15:56, Patrik Karlström <pa...@trixon.se> wrote:
> 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
I haven't noticed this with the platform. It's expected in NetBeans
because the conf has -J-Djava.lang.Runtime.level=FINE Is something in
your application setting up the same logging levels?
Having this enabled in the IDE is to get a stack trace in the log if
something unexpectedly calls System.exit() etc. and causes the IDE to
exit, as this can no longer be prevented.
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS] Security Manager removal implementation
Posted by Patrik Karlström <pa...@trixon.se>.
Thank you Neil and Michael, now I understand.
...and I had indeed added -J-Djava.lang.Runtime.level=FINE to my own
application.
/Patrik
Den lör 22 feb. 2025 kl 00:10 skrev Michael Bien <mb...@gmail.com>:
> Hi Patrik,
>
> this may look like an exception but it is just logger output to trace the
> caller of System.exit().
>
> if you take a look at recent javadoc for that method, it mentions this as
> "implementation note":
>
> https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/Runtime.html#exit(int)
>
> The main reason we set it is to be able to distinguished between a hard
> jvm crash and a regular exit (possibly some third party plugin)
> when someone is opening a bug report for example. Nothing should ever call
> exit outside NB code - this is just there to verify that it is indeed the
> case.
>
> We could potentially move this one day into a JFR log (using custom
> config), since there are events for that too - but having it as last entry
> in the log is probably also useful.
>
> best regards,
> michael
>
> On 21.02.25 16:54, Patrik Karlström wrote:
> > 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 <mb...@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-unsubscribe@netbeans.apache.org
> >>>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
> >>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
> >> For additional commands, e-mail: dev-help@netbeans.apache.org
> >>
> >> For further information about the NetBeans mailing lists, visit:
> >> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
> >>
> >>
> >>
> >>
>
>
Re: [DISCUSS] Security Manager removal implementation
Posted by Michael Bien <mb...@gmail.com>.
Hi Patrik,
this may look like an exception but it is just logger output to trace the caller of System.exit().
if you take a look at recent javadoc for that method, it mentions this as "implementation note":
https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/Runtime.html#exit(int)
The main reason we set it is to be able to distinguished between a hard jvm crash and a regular exit (possibly some third party plugin)
when someone is opening a bug report for example. Nothing should ever call exit outside NB code - this is just there to verify that it is indeed the case.
We could potentially move this one day into a JFR log (using custom config), since there are events for that too - but having it as last entry in the log is probably also useful.
best regards,
michael
On 21.02.25 16:54, Patrik Karlström wrote:
> 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 <mb...@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-unsubscribe@netbeans.apache.org
>>>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
>>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
>> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS] Security Manager removal implementation
Posted by Patrik Karlström <pa...@trixon.se>.
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 <mb...@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-unsubscribe@netbeans.apache.org
> >>>>> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
> >>>> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>
Re: [DISCUSS] Security Manager removal implementation
Posted by Michael Bien <mb...@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-unsubscribe@netbeans.apache.org
>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
>>>> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS] Security Manager removal implementation
Posted by Michael Bien <mb...@gmail.com>.
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-unsubscribe@netbeans.apache.org
>>>> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
>>> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS] Security Manager removal implementation
Posted by Michael Bien <mb...@gmail.com>.
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-unsubscribe@netbeans.apache.org
>>> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
>> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists