Re: [VOTE] Clarifying our JDK Support Policy

2025-06-18 Thread Aleksey Yeshchenko
+1 > On 18 Jun 2025, at 14:24, Josh McKenzie wrote: > > We're at 10 binding +1. Need 3 more to move this across the line. > > On Tue, Jun 17, 2025, at 6:58 PM, Joseph Lynch wrote: >> +1 >> >> On Tue, Jun 17, 2025 at 1:47 PM David Capwell > > wrote: >> +1 >> >>> On J

Re: [VOTE] Clarifying our JDK Support Policy

2025-06-18 Thread C. Scott Andreas
+1On Jun 18, 2025, at 11:08 AM, Aleksey Yeshchenko wrote:+1On 18 Jun 2025, at 14:24, Josh McKenzie wrote:We're at 10 binding +1. Need 3 more to move this across the line.On Tue, Jun 17, 2025, at 6:58 PM, Joseph Lynch wrote:+1On Tue, Jun 17, 2025 at 1:47 PM David Capwell wrot

Re: [DISCUSS] CASSSIDECAR-254 - Enabling sidecar to collect async profiles

2025-06-18 Thread Doug Rohrer
I agree that exposing the raw execute method is a bad idea, for both the reason David mentions but also the foot-gun problem - there are a lot of ways that calling “execute” can cause you to overwrite files and we really shouldn’t expose an arbitrary file overwrite feature on purpose if we can a

Re: [VOTE] Clarifying our JDK Support Policy

2025-06-18 Thread Josh McKenzie
We're at 10 binding +1. Need 3 more to move this across the line. On Tue, Jun 17, 2025, at 6:58 PM, Joseph Lynch wrote: > +1 > > On Tue, Jun 17, 2025 at 1:47 PM David Capwell wrote: >> +1 >> >>> On Jun 17, 2025, at 3:44 AM, Štefan Miklošovič >>> wrote: >>> >>> +1 >>> >>> On Fri, Jun 13, 202

Re: [DISCUSS] CASSSIDECAR-254 - Enabling sidecar to collect async profiles

2025-06-18 Thread Abe Ratnofsky
Another vote in favor of including async-profiler as a library in C*. The new heatmap format in async-profiler 4.0[1] is excellent and makes long-running profiles miles more useful than a plain flamegraph, but it requires a post-processing step after a JFR is collected, which would require a dep

Re: [VOTE] Clarifying our JDK Support Policy

2025-06-18 Thread Jordan West
+1 On Wed, Jun 18, 2025 at 8:28 AM C. Scott Andreas wrote: > +1 > > On Jun 18, 2025, at 11:08 AM, Aleksey Yeshchenko > wrote: > > +1 > > On 18 Jun 2025, at 14:24, Josh McKenzie wrote: > > We're at 10 binding +1. Need 3 more to move this across the line. > > On Tue, Jun 17, 2025, at 6:58 PM, J

Re: [DISCUSS] CASSSIDECAR-254 - Enabling sidecar to collect async profiles

2025-06-18 Thread Abe Ratnofsky
Another vote in favor of including async-profiler as a library in C*. The new heatmap format in async-profiler 4.0[1] is excellent and makes long-running profiles miles more useful than a plain flamegraph, but it requires a post-processing step after a JFR is collected, which would require a dep

Re: [VOTE] Clarifying our JDK Support Policy

2025-06-18 Thread Dmitry Konstantinov
+1 (nb) There are the following pain points (mentioned in the discussion thread as well) related to this option but other options look even worse :-), so I think it is a fair cost: - potential necessity to update 3rd party dependencies in GA branches to support a newer JDK - deprecating

Re: [VOTE] Clarifying our JDK Support Policy

2025-06-18 Thread Patrick McFadin
+1 On Wed, Jun 18, 2025 at 3:17 PM Dmitry Konstantinov wrote: > +1 (nb) > > There are the following pain points (mentioned in the discussion thread as > well) related to this option but other options look even worse :-), so I > think it is a fair cost: > >- potential necessity to update 3rd