From hirt at openjdk.org  Mon Feb  2 13:09:16 2026
From: hirt at openjdk.org (Marcus Hirt)
Date: Mon, 2 Feb 2026 13:09:16 GMT
Subject: Integrated: 8528: UI tests fail after platform upgrade
In-Reply-To: <yTIFxLwo-loIrnU7IVM-WZvKK9l1CTmgoVLYV4iT4Qc=.86e0a5ff-a215-4c1e-9c90-d171e36caeb5@github.com>
References: <yTIFxLwo-loIrnU7IVM-WZvKK9l1CTmgoVLYV4iT4Qc=.86e0a5ff-a215-4c1e-9c90-d171e36caeb5@github.com>
Message-ID: <VO51g2wZqXZR35rTkpq1uton-GURjqLRUYKfVK0UGVg=.8ad5a156-92b1-40d4-9b9c-d292bb30d17d@github.com>

On Fri, 30 Jan 2026 18:19:17 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

> The uitests also caught a problem with the finalizer removal which is also fixed.

This pull request has now been integrated.

Changeset: a7a5ff70
Author:    Marcus Hirt <hirt at openjdk.org>
URL:       https://git.openjdk.org/jmc/commit/a7a5ff7071702da561572745f76db454fe9eccf5
Stats:     25 lines in 3 files changed: 7 ins; 12 del; 6 mod

8528: UI tests fail after platform upgrade

Reviewed-by: aptmac

-------------

PR: https://git.openjdk.org/jmc/pull/706

From hirt at openjdk.org  Mon Feb  2 13:11:22 2026
From: hirt at openjdk.org (Marcus Hirt)
Date: Mon, 2 Feb 2026 13:11:22 GMT
Subject: RFR: 8476: Websocket server is tied to JfrEditor
In-Reply-To: <A6FmgeU8BxZdI8Z7adLM7k7Ig08no9HlOHRph5g3XaI=.656131b2-673a-45dd-b0cd-b8f1165321a5@github.com>
References: <A6FmgeU8BxZdI8Z7adLM7k7Ig08no9HlOHRph5g3XaI=.656131b2-673a-45dd-b0cd-b8f1165321a5@github.com>
Message-ID: <l7YKg6GAPq6HSsKYc1baA6ClmLxYz722leF0Ag9AJF8=.7791dbe9-3990-4914-bdb6-ea50b9f3f1f8@github.com>

On Wed, 7 Jan 2026 19:23:18 GMT, Alex Macdonald <aptmac at openjdk.org> wrote:

> This PR addresses JMC-8476, in which the current websocket server implemention ties the server to a JfrEditor page.
> 
> At the moment, the Websocket server that is used to send selection data is created from within a JfrEditor page. So every time you open a new recording file, the JfrEditor code tries to start a new websocket server. This is a problem because there is only one field in the JMC settings to set the port number, and it is global to the application. So if I open recording-1, and then use the preferences menu to start the websocket server on port 8029, if I then open up recording-2 it will also try to open a websocket server on port 8029, and fail. As a result, sending data from recording-1 will work, but recording-2 will not (this can be seen in my "before" gif below).
> 
> I have extracted the websocket code out into it's own package and made it such that there is one server for the JMC application. So now if you toggle between recordings you can still send data to whatever application you want over websocket.
> 
> Before:
> (exception thrown when trying to send events from the second recording)
> ![before](https://github.com/user-attachments/assets/8e9a3c97-f974-4409-99ea-6f86eb33e8cb)
> 
> After:
> (selecting events from multiple recordings now works)
> ![after](https://github.com/user-attachments/assets/11ff55af-f691-4780-b504-adf4847be3e8)

Very nice! :)

Marked as reviewed by hirt (Lead).

-------------

PR Review: https://git.openjdk.org/jmc/pull/698#pullrequestreview-3739301846
PR Review: https://git.openjdk.org/jmc/pull/698#pullrequestreview-3739303305

From hirt at openjdk.org  Mon Feb  2 13:12:26 2026
From: hirt at openjdk.org (Marcus Hirt)
Date: Mon, 2 Feb 2026 13:12:26 GMT
Subject: RFR: 8475: Writing events with fields not explicitly set can
 corrupt the recording [v2]
In-Reply-To: <HZ3o6BzgwA-V8iI4ra5tOvWEw8EKc2M4wdD3rUKGZz0=.173b7bd1-22a2-4611-827e-c9066010febc@github.com>
References: <pu1GsrnjX-UVUD6Pr_SumH9KEe2bXbKMtNEjW8YWuEo=.79e00cb5-3b0f-4d3b-bd92-cba42bf8429d@github.com>
 <HZ3o6BzgwA-V8iI4ra5tOvWEw8EKc2M4wdD3rUKGZz0=.173b7bd1-22a2-4611-827e-c9066010febc@github.com>
Message-ID: <bQ5W6h9OKbYqY9auX4rtNAtbvdqrxoBtmGTpHZq5o-s=.687f9e7b-8b0b-49ab-9e30-f89ecb6f3be7@github.com>

On Wed, 3 Dec 2025 16:24:51 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

>> ## Summary
>> Fixes an issue where events written with builtin type fields that are not explicitly set could cause field misalignment during JFR recording parsing, leading to corrupted field values.
>> 
>> ## Problem
>> When writing JFR events using the Writer API without explicitly setting values for builtin type fields (byte, char, short, int, long, float, double, boolean, string), the previous implementation in `Chunk.writeBuiltinType()` would skip writing null builtin values (except for strings). This caused field alignment issues during parsing, where subsequent field values would be read at incorrect offsets.
>> 
>> ## Solution
>> Modified `Chunk.writeBuiltinType()` (lines 88-150) to write appropriate default values for null builtin types instead of skipping them:
>> - Numeric types (byte, char, short, int, long, float, double): Write `0`
>> - Boolean: Write `false`  
>> - String: Continue to write null encoding (existing behavior)
>> 
>> Additionally enhanced `TypedValueImpl.getDefaultImplicitFieldValue()` to provide `System.nanoTime()` as default for `@Timestamp` annotated fields in event types, ensuring valid monotonic timestamps.
>> 
>> ## Testing
>> Added comprehensive test `ImplicitEventFieldsTest.eventWithAllBuiltinFieldsUnset()` that:
>> - Creates an event with all 9 builtin type fields
>> - Writes the event without setting any builtin field values
>> - Includes a final field with an explicit value (99999L) to verify alignment
>> - Verifies all default values are correct and the explicit field reads back correctly
>> 
>> All 277 existing tests pass with the changes.
>> 
>> ## Files Changed
>> - `Chunk.java`: Fixed builtin type serialization to write defaults instead of skipping
>> - `TypedValueImpl.java`: Enhanced default value handling for timestamp fields
>> - `ImplicitEventFieldsTest.java`: Added comprehensive test for builtin defaults
>> - `Type.java`, `TypedValueBuilder.java`: Enhanced documentation
>> 
>> Fixes #8475
>> 
>> ? Generated with [Claude Code](https://claude.com/claude-code)
>
> Jaroslav Bachorik has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   8475: Writing events with fields not explicitly set can corrupt the recording

Marked as reviewed by hirt (Lead).

-------------

PR Review: https://git.openjdk.org/jmc/pull/690#pullrequestreview-3739307836

From jbachorik at openjdk.org  Mon Feb  2 13:33:34 2026
From: jbachorik at openjdk.org (Jaroslav Bachorik)
Date: Mon, 2 Feb 2026 13:33:34 GMT
Subject: RFR: 8475: Writing events with fields not explicitly set can
 corrupt the recording [v2]
In-Reply-To: <HZ3o6BzgwA-V8iI4ra5tOvWEw8EKc2M4wdD3rUKGZz0=.173b7bd1-22a2-4611-827e-c9066010febc@github.com>
References: <pu1GsrnjX-UVUD6Pr_SumH9KEe2bXbKMtNEjW8YWuEo=.79e00cb5-3b0f-4d3b-bd92-cba42bf8429d@github.com>
 <HZ3o6BzgwA-V8iI4ra5tOvWEw8EKc2M4wdD3rUKGZz0=.173b7bd1-22a2-4611-827e-c9066010febc@github.com>
Message-ID: <4wZr8uSRQZmpnZKQ2276ojxMEfHMxWQMxDCvdnr8kP4=.afc798a9-5c3e-4bce-877d-7b2f06959a3b@github.com>

On Wed, 3 Dec 2025 16:24:51 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

>> ## Summary
>> Fixes an issue where events written with builtin type fields that are not explicitly set could cause field misalignment during JFR recording parsing, leading to corrupted field values.
>> 
>> ## Problem
>> When writing JFR events using the Writer API without explicitly setting values for builtin type fields (byte, char, short, int, long, float, double, boolean, string), the previous implementation in `Chunk.writeBuiltinType()` would skip writing null builtin values (except for strings). This caused field alignment issues during parsing, where subsequent field values would be read at incorrect offsets.
>> 
>> ## Solution
>> Modified `Chunk.writeBuiltinType()` (lines 88-150) to write appropriate default values for null builtin types instead of skipping them:
>> - Numeric types (byte, char, short, int, long, float, double): Write `0`
>> - Boolean: Write `false`  
>> - String: Continue to write null encoding (existing behavior)
>> 
>> Additionally enhanced `TypedValueImpl.getDefaultImplicitFieldValue()` to provide `System.nanoTime()` as default for `@Timestamp` annotated fields in event types, ensuring valid monotonic timestamps.
>> 
>> ## Testing
>> Added comprehensive test `ImplicitEventFieldsTest.eventWithAllBuiltinFieldsUnset()` that:
>> - Creates an event with all 9 builtin type fields
>> - Writes the event without setting any builtin field values
>> - Includes a final field with an explicit value (99999L) to verify alignment
>> - Verifies all default values are correct and the explicit field reads back correctly
>> 
>> All 277 existing tests pass with the changes.
>> 
>> ## Files Changed
>> - `Chunk.java`: Fixed builtin type serialization to write defaults instead of skipping
>> - `TypedValueImpl.java`: Enhanced default value handling for timestamp fields
>> - `ImplicitEventFieldsTest.java`: Added comprehensive test for builtin defaults
>> - `Type.java`, `TypedValueBuilder.java`: Enhanced documentation
>> 
>> Fixes #8475
>> 
>> ? Generated with [Claude Code](https://claude.com/claude-code)
>
> Jaroslav Bachorik has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   8475: Writing events with fields not explicitly set can corrupt the recording

?  Thanks!

-------------

PR Comment: https://git.openjdk.org/jmc/pull/690#issuecomment-3835126997

From jbachorik at openjdk.org  Mon Feb  2 13:33:36 2026
From: jbachorik at openjdk.org (Jaroslav Bachorik)
Date: Mon, 2 Feb 2026 13:33:36 GMT
Subject: Integrated: 8475: Writing events with fields not explicitly set can
 corrupt the recording
In-Reply-To: <pu1GsrnjX-UVUD6Pr_SumH9KEe2bXbKMtNEjW8YWuEo=.79e00cb5-3b0f-4d3b-bd92-cba42bf8429d@github.com>
References: <pu1GsrnjX-UVUD6Pr_SumH9KEe2bXbKMtNEjW8YWuEo=.79e00cb5-3b0f-4d3b-bd92-cba42bf8429d@github.com>
Message-ID: <LwIkCT-DeVQnPkQaYiZ34LFaVC1YsTDahmFy9HE2JgY=.cf752e3f-69cc-4d6d-b126-7d8c7178321b@github.com>

On Wed, 3 Dec 2025 10:18:08 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

> ## Summary
> Fixes an issue where events written with builtin type fields that are not explicitly set could cause field misalignment during JFR recording parsing, leading to corrupted field values.
> 
> ## Problem
> When writing JFR events using the Writer API without explicitly setting values for builtin type fields (byte, char, short, int, long, float, double, boolean, string), the previous implementation in `Chunk.writeBuiltinType()` would skip writing null builtin values (except for strings). This caused field alignment issues during parsing, where subsequent field values would be read at incorrect offsets.
> 
> ## Solution
> Modified `Chunk.writeBuiltinType()` (lines 88-150) to write appropriate default values for null builtin types instead of skipping them:
> - Numeric types (byte, char, short, int, long, float, double): Write `0`
> - Boolean: Write `false`  
> - String: Continue to write null encoding (existing behavior)
> 
> Additionally enhanced `TypedValueImpl.getDefaultImplicitFieldValue()` to provide `System.nanoTime()` as default for `@Timestamp` annotated fields in event types, ensuring valid monotonic timestamps.
> 
> ## Testing
> Added comprehensive test `ImplicitEventFieldsTest.eventWithAllBuiltinFieldsUnset()` that:
> - Creates an event with all 9 builtin type fields
> - Writes the event without setting any builtin field values
> - Includes a final field with an explicit value (99999L) to verify alignment
> - Verifies all default values are correct and the explicit field reads back correctly
> 
> All 277 existing tests pass with the changes.
> 
> ## Files Changed
> - `Chunk.java`: Fixed builtin type serialization to write defaults instead of skipping
> - `TypedValueImpl.java`: Enhanced default value handling for timestamp fields
> - `ImplicitEventFieldsTest.java`: Added comprehensive test for builtin defaults
> - `Type.java`, `TypedValueBuilder.java`: Enhanced documentation
> 
> Fixes #8475
> 
> ? Generated with [Claude Code](https://claude.com/claude-code)

This pull request has now been integrated.

Changeset: 020f06d7
Author:    Jaroslav Bachorik <jbachorik at openjdk.org>
URL:       https://git.openjdk.org/jmc/commit/020f06d717e32451b641b6b75e391410f0089b69
Stats:     430 lines in 5 files changed: 416 ins; 4 del; 10 mod

8475: Writing events with fields not explicitly set can corrupt the recording

Reviewed-by: hirt

-------------

PR: https://git.openjdk.org/jmc/pull/690

From hirt at openjdk.org  Mon Feb  2 13:40:36 2026
From: hirt at openjdk.org (Marcus Hirt)
Date: Mon, 2 Feb 2026 13:40:36 GMT
Subject: RFR: 5561: Support for Crypto Events in JMC [v4]
In-Reply-To: <q8ZFTKt-Acp_a3HvUWKJrNdON7beqXT36tgVO3qNHp0=.17718385-ac0d-413d-b590-736438a3b70e@github.com>
References: <L3Wlpr7zk0rQE9qSVzkTehMZtHUwr141I2ZFjOF0060=.7ceacbf6-67d0-462d-a35e-7d135046ec42@github.com>
 <q8ZFTKt-Acp_a3HvUWKJrNdON7beqXT36tgVO3qNHp0=.17718385-ac0d-413d-b590-736438a3b70e@github.com>
Message-ID: <VBnqrGT84sgX-o6MbEAfrK3x2iBJpqTIGJuA44gtWOU=.33756a0f-e4b7-4a91-a611-814991c5b5c7@github.com>

On Tue, 23 Dec 2025 22:45:13 GMT, Suchita Chaturvedi <schaturvedi at openjdk.org> wrote:

>> This PR enhances the JMC UI for adding new information related to crypto events: specifically X509CertificateEvent.
>> 
>> This PR adds a new rule with respect to X509CertificateEvent which provides alert related to expired/expiring certificates and weak signature algorithms or weak key length or key type. The rule gives a basic overview of all the certificate ids which needs action or attention, however complete details are provided as part of a new screen - Security.
>> 
>> Attaching the screenshots here for better reference:
>> 
>> Rule Page:
>> 
>> <img width="362" height="373" alt="image" src="https://github.com/user-attachments/assets/4707e6b2-76be-4b1e-9f32-c6139851d86c" />
>> 
>> Security Screen Page:
>> 
>> <img width="959" height="385" alt="image" src="https://github.com/user-attachments/assets/5026e2b7-2754-47bc-a42d-5672f9f087d7" />
>
> Suchita Chaturvedi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing spotless failure

Changes requested by hirt (Lead).

application/org.openjdk.jmc.docs/html/SecurityPage.htm line 4:

> 2:   PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
> 3: <!--
> 4:    Copyright (c) 2018, 2025, Oracle and/or its affiliates. All rights reserved.

All the copyrights should now be 2026.

core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/security/CryptoUtil.java line 45:

> 43: import java.util.Map;
> 44: import java.util.concurrent.TimeUnit;
> 45: 

Perhaps a class comment explaining the class.

core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/security/CryptoUtil.java line 70:

> 68: 			} else if (keyLength == 1024) {
> 69: 				remark = ACTION.concat(Messages.getString(Messages.Crypto_RSA_KEY_SIZE_1024)).concat(remark);
> 70: 			} else if (keyLength < 2048) {

Should all these constants be defined somewhere, e.g.:
  private static final int RSA_MINIMUM_KEY_SIZE = 1024;                                                                                                                  
  private static final int RSA_RECOMMENDED_KEY_SIZE = 2048;

core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/security/CryptoUtil.java line 111:

> 109: 	}
> 110: 
> 111: 	public static String getCryptoIcon(

Splitting up the determination of the severity level and then deciding at the icon at the end might be cleaner. Perhaps using an enum for the severity level.

core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/security/CryptoUtil.java line 168:

> 166: 	}
> 167: 
> 168: 	public static String getCryptoRuleResult(

There is a lot of code duplication. How about separating out some of the key functionality, e.g. :

  private static boolean isWeakSignatureAlgorithm(String signatureAlgorithm) {                                                                                           
      return signatureAlgorithm.contains("MD2") || signatureAlgorithm.contains("MD5");                                                                                   
  }

core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/security/CryptoUtil.java line 231:

> 229: 
> 230: 		if (remarks.isEmpty()) {
> 231: 			remarks.add(Map.entry(OK, "Everything is fine"));

Should be externalised.

core/org.openjdk.jmc.common/src/main/resources/org/openjdk/jmc/common/messages/internal/messages.properties line 218:

> 216: Crypto_MD2= MD2 signature. 
> 217: Crypto_MD5= MD5 signature. 
> 218: Crypto_RSA_INSUFFICIENT_KEY_SIZE= RSA signature with insufficient key size. 

These could be improved by being a bit more concrete and specifying the expectations. E.g. "RSA key size {0} bits is below minimum {1} bits."

-------------

PR Review: https://git.openjdk.org/jmc/pull/686#pullrequestreview-3739355844
PR Review Comment: https://git.openjdk.org/jmc/pull/686#discussion_r2754348826
PR Review Comment: https://git.openjdk.org/jmc/pull/686#discussion_r2754300269
PR Review Comment: https://git.openjdk.org/jmc/pull/686#discussion_r2754339581
PR Review Comment: https://git.openjdk.org/jmc/pull/686#discussion_r2754323542
PR Review Comment: https://git.openjdk.org/jmc/pull/686#discussion_r2754308640
PR Review Comment: https://git.openjdk.org/jmc/pull/686#discussion_r2754327081
PR Review Comment: https://git.openjdk.org/jmc/pull/686#discussion_r2754371011

From aptmac at openjdk.org  Mon Feb  2 14:19:03 2026
From: aptmac at openjdk.org (Alex Macdonald)
Date: Mon, 2 Feb 2026 14:19:03 GMT
Subject: Integrated: 8476: Websocket server is tied to JfrEditor
In-Reply-To: <A6FmgeU8BxZdI8Z7adLM7k7Ig08no9HlOHRph5g3XaI=.656131b2-673a-45dd-b0cd-b8f1165321a5@github.com>
References: <A6FmgeU8BxZdI8Z7adLM7k7Ig08no9HlOHRph5g3XaI=.656131b2-673a-45dd-b0cd-b8f1165321a5@github.com>
Message-ID: <XuUTnPKb-OaJJX0IhcW3c6Pj9y50MVJ51YzT5eLmPXw=.029adeb9-c363-4bb0-9606-ab05d60cc949@github.com>

On Wed, 7 Jan 2026 19:23:18 GMT, Alex Macdonald <aptmac at openjdk.org> wrote:

> This PR addresses JMC-8476, in which the current websocket server implemention ties the server to a JfrEditor page.
> 
> At the moment, the Websocket server that is used to send selection data is created from within a JfrEditor page. So every time you open a new recording file, the JfrEditor code tries to start a new websocket server. This is a problem because there is only one field in the JMC settings to set the port number, and it is global to the application. So if I open recording-1, and then use the preferences menu to start the websocket server on port 8029, if I then open up recording-2 it will also try to open a websocket server on port 8029, and fail. As a result, sending data from recording-1 will work, but recording-2 will not (this can be seen in my "before" gif below).
> 
> I have extracted the websocket code out into it's own package and made it such that there is one server for the JMC application. So now if you toggle between recordings you can still send data to whatever application you want over websocket.
> 
> Before:
> (exception thrown when trying to send events from the second recording)
> ![before](https://github.com/user-attachments/assets/8e9a3c97-f974-4409-99ea-6f86eb33e8cb)
> 
> After:
> (selecting events from multiple recordings now works)
> ![after](https://github.com/user-attachments/assets/11ff55af-f691-4780-b504-adf4847be3e8)

This pull request has now been integrated.

Changeset: f9ba5ef0
Author:    Alex Macdonald <aptmac at openjdk.org>
URL:       https://git.openjdk.org/jmc/commit/f9ba5ef03796c1c05640c1180e003c6649f2e81a
Stats:     1154 lines in 23 files changed: 739 ins; 393 del; 22 mod

8476: Websocket server is tied to JfrEditor

Reviewed-by: hirt

-------------

PR: https://git.openjdk.org/jmc/pull/698

From hirt at openjdk.org  Mon Feb  2 15:16:34 2026
From: hirt at openjdk.org (Marcus Hirt)
Date: Mon, 2 Feb 2026 15:16:34 GMT
Subject: RFR: 5561: Support for Crypto Events in JMC [v4]
In-Reply-To: <q8ZFTKt-Acp_a3HvUWKJrNdON7beqXT36tgVO3qNHp0=.17718385-ac0d-413d-b590-736438a3b70e@github.com>
References: <L3Wlpr7zk0rQE9qSVzkTehMZtHUwr141I2ZFjOF0060=.7ceacbf6-67d0-462d-a35e-7d135046ec42@github.com>
 <q8ZFTKt-Acp_a3HvUWKJrNdON7beqXT36tgVO3qNHp0=.17718385-ac0d-413d-b590-736438a3b70e@github.com>
Message-ID: <UpTCk71ZUQhKQ3MZ0EW66l790hPaYyUAqqolRt1qQ5E=.41daec1c-209d-4f9a-af07-b471ec784d2f@github.com>

On Tue, 23 Dec 2025 22:45:13 GMT, Suchita Chaturvedi <schaturvedi at openjdk.org> wrote:

>> This PR enhances the JMC UI for adding new information related to crypto events: specifically X509CertificateEvent.
>> 
>> This PR adds a new rule with respect to X509CertificateEvent which provides alert related to expired/expiring certificates and weak signature algorithms or weak key length or key type. The rule gives a basic overview of all the certificate ids which needs action or attention, however complete details are provided as part of a new screen - Security.
>> 
>> Attaching the screenshots here for better reference:
>> 
>> Rule Page:
>> 
>> <img width="362" height="373" alt="image" src="https://github.com/user-attachments/assets/4707e6b2-76be-4b1e-9f32-c6139851d86c" />
>> 
>> Security Screen Page:
>> 
>> <img width="959" height="385" alt="image" src="https://github.com/user-attachments/assets/5026e2b7-2754-47bc-a42d-5672f9f087d7" />
>
> Suchita Chaturvedi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing spotless failure

application/org.openjdk.jmc.ui/src/main/java/org/openjdk/jmc/ui/UIPlugin.java line 195:

> 193: 	public static final String ICON_FIND = "search-glass.png"; //$NON-NLS-1$
> 194: 
> 195: 	public static final String ICON_CRYPTO_ACTION = "crypto_action.svg"; //$NON-NLS-1$

These keep being created over and over. Should they be registered (UIPlugin.registerImage(...)) so that we don't leak images?
E.g. 

registerImage(registry, ICON_CRYPTO_ACTION, ICON_CRYPTO_ACTION);                                                                                                       
etc.

-------------

PR Review Comment: https://git.openjdk.org/jmc/pull/686#discussion_r2754838657

From hirt at openjdk.org  Mon Feb  2 15:16:34 2026
From: hirt at openjdk.org (Marcus Hirt)
Date: Mon, 2 Feb 2026 15:16:34 GMT
Subject: RFR: 5561: Support for Crypto Events in JMC [v4]
In-Reply-To: <UpTCk71ZUQhKQ3MZ0EW66l790hPaYyUAqqolRt1qQ5E=.41daec1c-209d-4f9a-af07-b471ec784d2f@github.com>
References: <L3Wlpr7zk0rQE9qSVzkTehMZtHUwr141I2ZFjOF0060=.7ceacbf6-67d0-462d-a35e-7d135046ec42@github.com>
 <q8ZFTKt-Acp_a3HvUWKJrNdON7beqXT36tgVO3qNHp0=.17718385-ac0d-413d-b590-736438a3b70e@github.com>
 <UpTCk71ZUQhKQ3MZ0EW66l790hPaYyUAqqolRt1qQ5E=.41daec1c-209d-4f9a-af07-b471ec784d2f@github.com>
Message-ID: <znFadyveoWfy0yTJZ2WV8VRaudBkv-gGvt3bMVOMy4k=.a45b4a19-ef48-42aa-8ff7-090ffb06ae2e@github.com>

On Mon, 2 Feb 2026 15:11:25 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

>> Suchita Chaturvedi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixing spotless failure
>
> application/org.openjdk.jmc.ui/src/main/java/org/openjdk/jmc/ui/UIPlugin.java line 195:
> 
>> 193: 	public static final String ICON_FIND = "search-glass.png"; //$NON-NLS-1$
>> 194: 
>> 195: 	public static final String ICON_CRYPTO_ACTION = "crypto_action.svg"; //$NON-NLS-1$
> 
> These keep being created over and over. Should they be registered (UIPlugin.registerImage(...)) so that we don't leak images?
> E.g. 
> 
> registerImage(registry, ICON_CRYPTO_ACTION, ICON_CRYPTO_ACTION);                                                                                                       
> etc.

Then, instead of getting the descriptors and creating the images in the label provider, just do UIPlugin.getDefault().getImage(UIPlugin.ICON_CRYPTO_ACTION) and so on.

-------------

PR Review Comment: https://git.openjdk.org/jmc/pull/686#discussion_r2754850928

From hirt at openjdk.org  Mon Feb  2 15:25:58 2026
From: hirt at openjdk.org (Marcus Hirt)
Date: Mon, 2 Feb 2026 15:25:58 GMT
Subject: RFR: 6832: Should allow plotting line charts for all quantities
 [v2]
In-Reply-To: <BqDJDZzLzuW_ZBdL5hVr9Kt_3lIHp2HOvKZ_6EBXER4=.e1499d82-4a01-49a3-bd2a-5ce18c5375d3@github.com>
References: <iOjydd_VWy1O-7YOp24id9trousaAKK_WzY0lzVbmT8=.2e2acd01-b1c9-4237-82e7-2f6341f32438@github.com>
 <BqDJDZzLzuW_ZBdL5hVr9Kt_3lIHp2HOvKZ_6EBXER4=.e1499d82-4a01-49a3-bd2a-5ce18c5375d3@github.com>
Message-ID: <dk3qtBcBNjMo0Q7sbgJaKpvElJDfpasVMWyUnHayIjk=.f1f7c6b3-1b29-422c-a5bd-603a8f90bfdc@github.com>

On Mon, 19 Jan 2026 18:34:21 GMT, Aymane Harmaz <aharmaz at openjdk.org> wrote:

>> This PR makes sure line charts cover all the events across multiple IItemIterables, and makes it possible for linear quantities to be represented as line charts on custom pages.
>
> Aymane Harmaz has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - update copyright year in AttributeComponentConfiguration
>  - implemented merge sorting of items from multiple chunks
>  - 6832: Should allow plotting line charts for all quantities

Changes requested by hirt (Lead).

core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/collection/PeekingIterator.java line 55:

> 53: 		if (!this.hasPeeked) {
> 54: 			this.hasPeeked = true;
> 55: 			this.peekedElement = this.sourceIterator.next();

Should there be a hasNext() check here?

-------------

PR Review: https://git.openjdk.org/jmc/pull/688#pullrequestreview-3740147357
PR Review Comment: https://git.openjdk.org/jmc/pull/688#discussion_r2754889844

From aharmaz at openjdk.org  Mon Feb  2 18:33:02 2026
From: aharmaz at openjdk.org (Aymane Harmaz)
Date: Mon, 2 Feb 2026 18:33:02 GMT
Subject: RFR: 6832: Should allow plotting line charts for all quantities
 [v3]
In-Reply-To: <iOjydd_VWy1O-7YOp24id9trousaAKK_WzY0lzVbmT8=.2e2acd01-b1c9-4237-82e7-2f6341f32438@github.com>
References: <iOjydd_VWy1O-7YOp24id9trousaAKK_WzY0lzVbmT8=.2e2acd01-b1c9-4237-82e7-2f6341f32438@github.com>
Message-ID: <WKh0EbX2gEd_SFfcPocIvYhYiqN1K08L6RgzzBPesf4=.3e295336-6faa-4a65-a4c8-2dca4183cba9@github.com>

> This PR makes sure line charts cover all the events across multiple IItemIterables, and makes it possible for linear quantities to be represented as line charts on custom pages.

Aymane Harmaz has updated the pull request incrementally with one additional commit since the last revision:

  prevented access when no more elements are available

-------------

Changes:
  - all: https://git.openjdk.org/jmc/pull/688/files
  - new: https://git.openjdk.org/jmc/pull/688/files/4e2ff3f4..b3ecd632

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jmc&pr=688&range=02
 - incr: https://webrevs.openjdk.org/?repo=jmc&pr=688&range=01-02

  Stats: 7 lines in 1 file changed: 7 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jmc/pull/688.diff
  Fetch: git fetch https://git.openjdk.org/jmc.git pull/688/head:pull/688

PR: https://git.openjdk.org/jmc/pull/688

From aharmaz at openjdk.org  Mon Feb  2 18:35:50 2026
From: aharmaz at openjdk.org (Aymane Harmaz)
Date: Mon, 2 Feb 2026 18:35:50 GMT
Subject: RFR: 6832: Should allow plotting line charts for all quantities
 [v2]
In-Reply-To: <dk3qtBcBNjMo0Q7sbgJaKpvElJDfpasVMWyUnHayIjk=.f1f7c6b3-1b29-422c-a5bd-603a8f90bfdc@github.com>
References: <iOjydd_VWy1O-7YOp24id9trousaAKK_WzY0lzVbmT8=.2e2acd01-b1c9-4237-82e7-2f6341f32438@github.com>
 <BqDJDZzLzuW_ZBdL5hVr9Kt_3lIHp2HOvKZ_6EBXER4=.e1499d82-4a01-49a3-bd2a-5ce18c5375d3@github.com>
 <dk3qtBcBNjMo0Q7sbgJaKpvElJDfpasVMWyUnHayIjk=.f1f7c6b3-1b29-422c-a5bd-603a8f90bfdc@github.com>
Message-ID: <YHR3tsNt6BYz6o9zeceg27OU4YHUuTcqLvn__buSWHY=.51e6dfc8-1883-41db-82c5-e1330cb76459@github.com>

On Mon, 2 Feb 2026 15:21:42 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

>> Aymane Harmaz has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
>> 
>>  - update copyright year in AttributeComponentConfiguration
>>  - implemented merge sorting of items from multiple chunks
>>  - 6832: Should allow plotting line charts for all quantities
>
> core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/collection/PeekingIterator.java line 55:
> 
>> 53: 		if (!this.hasPeeked) {
>> 54: 			this.hasPeeked = true;
>> 55: 			this.peekedElement = this.sourceIterator.next();
> 
> Should there be a hasNext() check here?

Yes, thanks for pointing that out, I have added the check in both `peek()` and `next()`

-------------

PR Review Comment: https://git.openjdk.org/jmc/pull/688#discussion_r2755715422

From aharmaz at openjdk.org  Mon Feb  2 19:35:36 2026
From: aharmaz at openjdk.org (Aymane Harmaz)
Date: Mon, 2 Feb 2026 19:35:36 GMT
Subject: RFR: 6832: Should allow plotting line charts for all quantities
 [v4]
In-Reply-To: <iOjydd_VWy1O-7YOp24id9trousaAKK_WzY0lzVbmT8=.2e2acd01-b1c9-4237-82e7-2f6341f32438@github.com>
References: <iOjydd_VWy1O-7YOp24id9trousaAKK_WzY0lzVbmT8=.2e2acd01-b1c9-4237-82e7-2f6341f32438@github.com>
Message-ID: <GiR2RyLB1-Iw2m4fLnThCTuPIrv3fnRmZ6LyNwM7moo=.b247168f-b369-4e3f-9bc9-9d9e70199d8c@github.com>

> This PR makes sure line charts cover all the events across multiple IItemIterables, and makes it possible for linear quantities to be represented as line charts on custom pages.

Aymane Harmaz has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - prevented access when no more elements are available
 - update copyright year in AttributeComponentConfiguration
 - implemented merge sorting of items from multiple chunks
 - 6832: Should allow plotting line charts for all quantities

-------------

Changes: https://git.openjdk.org/jmc/pull/688/files
  Webrev: https://webrevs.openjdk.org/?repo=jmc&pr=688&range=03
  Stats: 170 lines in 5 files changed: 135 ins; 12 del; 23 mod
  Patch: https://git.openjdk.org/jmc/pull/688.diff
  Fetch: git fetch https://git.openjdk.org/jmc.git pull/688/head:pull/688

PR: https://git.openjdk.org/jmc/pull/688

From hirt at openjdk.org  Tue Feb  3 18:09:43 2026
From: hirt at openjdk.org (Marcus Hirt)
Date: Tue, 3 Feb 2026 18:09:43 GMT
Subject: RFR: 8490: Include numeric types without Persister in
 "Add Filter from Attribute" menu [v5]
In-Reply-To: <WQnyGWty6e6H8VtA_WUPOVQbmYoSq0_AyJxgxNx0W7k=.f54386e9-2f53-4db4-8ad7-d8eef1b7b1f4@github.com>
References: <KvWGp_qdylhVNgyGRtbyGsVU8CgukBd2jZypNuRoXAQ=.757886d0-d5fc-4552-9ebd-a46f5ea6a90d@github.com>
 <WQnyGWty6e6H8VtA_WUPOVQbmYoSq0_AyJxgxNx0W7k=.f54386e9-2f53-4db4-8ad7-d8eef1b7b1f4@github.com>
Message-ID: <01YA0glXqS8oySF-nvQSfn_26GRHd12V6QPilEVugmw=.b1e2983a-66dd-458a-adb1-8ac109edca4a@github.com>

On Sat, 31 Jan 2026 14:55:49 GMT, youngledo <duke at openjdk.org> wrote:

>> ### Problem
>> 
>>   Attributes with numeric ContentTypes that don't have a Persister (such as primitive types: byte, short, int, long, float, double, char) are
>>   excluded from the "Add Filter from Attribute" context menu in the Event Browser's filter editor.
>> 
>> #### Steps to reproduce:
>>   1. Open a JFR file containing events with primitive numeric fields (e.g., Spring Framework's FlightRecorderStartupEvent with long eventId and
>>   long parentId)
>>   2. In Event Browser, right-click on a column ? Select "Show Filter"
>>   3. Right-click on the filter area ? Select "Add Filter from Attribute"
>>   4. Expected: All filterable attributes should appear in the menu
>>   5. Actual: Primitive numeric type attributes are missing from the menu
>> 
>> <img width="2420" height="1362" alt="image" src="https://github.com/user-attachments/assets/70bcb795-7a7b-42f0-a83e-e34cb8e50361" />
>> 
>> #### Root Cause
>> 
>>   The getPersistableAttributes() method in DataPageToolkit.java (line 1006-1007) filters attributes based on whether their ContentType has a
>>   Persister:
>> 
>>   ```java
>>   .filter(a -> a.equals(JfrAttributes.EVENT_TYPE) || (a.getContentType() instanceof RangeContentType)
>>       || (a.getContentType().getPersister() != null))
>>   ```
>> 
>>   However, primitive numeric types use these ContentTypes which don't have a Persister:
>>   - UnitLookup.RAW_NUMBER - used by all primitive numeric types (byte, short, int, long, float, double, char)
>>   - UnitLookup.RAW_LONG - used by some custom Long attributes
>>   - UnitLookup.COUNT, UnitLookup.INDEX, UnitLookup.IDENTIFIER - legacy numeric types
>> 
>>   These types return null from getPersister() (see ContentType.java:99-101), causing them to be filtered out.
>> 
>> ### Why this is incorrect:
>> 
>>   Even though these types cannot be persisted to strings, they fully support filtering via ItemFilters.equals(). Excluding them from the filter
>>   menu is inconsistent with their actual capabilities.
>> 
>> ### Solution
>> 
>>   Add a helper method isFilterableNumericType() to identify numeric ContentTypes that support filtering even without a Persister, and include them
>>    in the filter:
>> 
>> private static boolean isFilterableNumericType(IAttribute<?> attribute) {
>>       org.openjdk.jmc.common.unit.ContentType<?> ct = attribute.getContentType();
>>       return ct.equals(UnitLookup.RAW_NUMBER) || ct.equals(UnitLookup.RAW_LONG)|| ct.equals(UnitLookup.COUNT) || ct.equals(UnitLookup.INDEX)
>>               || ct.equals(UnitLookup.IDEN...
>
> youngledo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update copyright year to 2026
>  - Remove .claude/settings.local.json from version control
>    
>    This file should not be tracked as it contains local settings.
>    Added .claude/ to .gitignore to prevent future commits.
>    
>    Co-Authored-By: Claude Sonnet 4.5 <noreply at anthropic.com>

Will the removal of the .classpath files cause any trouble running JMC from within the Eclipse development environment? I am not perfectly sure, but I have a faint memory of a few of them being slightly specialized.

-------------

PR Comment: https://git.openjdk.org/jmc/pull/699#issuecomment-3842847737

From schaturvedi at openjdk.org  Tue Feb  3 22:03:31 2026
From: schaturvedi at openjdk.org (Suchita Chaturvedi)
Date: Tue, 3 Feb 2026 22:03:31 GMT
Subject: RFR: 5561: Support for Crypto Events in JMC [v5]
In-Reply-To: <L3Wlpr7zk0rQE9qSVzkTehMZtHUwr141I2ZFjOF0060=.7ceacbf6-67d0-462d-a35e-7d135046ec42@github.com>
References: <L3Wlpr7zk0rQE9qSVzkTehMZtHUwr141I2ZFjOF0060=.7ceacbf6-67d0-462d-a35e-7d135046ec42@github.com>
Message-ID: <55oXOCL9rDZaMnh8g8h3niwIwSl3c2fn7KB7PzfCDlc=.914afe0a-45d1-4a7a-ac91-7a9324c7b3ab@github.com>

> This PR enhances the JMC UI for adding new information related to crypto events: specifically X509CertificateEvent.
> 
> This PR adds a new rule with respect to X509CertificateEvent which provides alert related to expired/expiring certificates and weak signature algorithms or weak key length or key type. The rule gives a basic overview of all the certificate ids which needs action or attention, however complete details are provided as part of a new screen - Security.
> 
> Attaching the screenshots here for better reference:
> 
> Rule Page:
> 
> <img width="362" height="373" alt="image" src="https://github.com/user-attachments/assets/4707e6b2-76be-4b1e-9f32-c6139851d86c" />
> 
> Security Screen Page:
> 
> <img width="959" height="385" alt="image" src="https://github.com/user-attachments/assets/5026e2b7-2754-47bc-a42d-5672f9f087d7" />

Suchita Chaturvedi has updated the pull request incrementally with one additional commit since the last revision:

  Implemented review comments

-------------

Changes:
  - all: https://git.openjdk.org/jmc/pull/686/files
  - new: https://git.openjdk.org/jmc/pull/686/files/547cc3f4..a4ac49c4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jmc&pr=686&range=04
 - incr: https://webrevs.openjdk.org/?repo=jmc&pr=686&range=03-04

  Stats: 105 lines in 27 files changed: 34 ins; 0 del; 71 mod
  Patch: https://git.openjdk.org/jmc/pull/686.diff
  Fetch: git fetch https://git.openjdk.org/jmc.git pull/686/head:pull/686

PR: https://git.openjdk.org/jmc/pull/686

From schaturvedi at openjdk.org  Tue Feb  3 22:03:36 2026
From: schaturvedi at openjdk.org (Suchita Chaturvedi)
Date: Tue, 3 Feb 2026 22:03:36 GMT
Subject: RFR: 5561: Support for Crypto Events in JMC [v4]
In-Reply-To: <VBnqrGT84sgX-o6MbEAfrK3x2iBJpqTIGJuA44gtWOU=.33756a0f-e4b7-4a91-a611-814991c5b5c7@github.com>
References: <L3Wlpr7zk0rQE9qSVzkTehMZtHUwr141I2ZFjOF0060=.7ceacbf6-67d0-462d-a35e-7d135046ec42@github.com>
 <q8ZFTKt-Acp_a3HvUWKJrNdON7beqXT36tgVO3qNHp0=.17718385-ac0d-413d-b590-736438a3b70e@github.com>
 <VBnqrGT84sgX-o6MbEAfrK3x2iBJpqTIGJuA44gtWOU=.33756a0f-e4b7-4a91-a611-814991c5b5c7@github.com>
Message-ID: <LAj17iuajpTd3YeboWDJ5rqWeubyFSTLgA6Ryc58w-Q=.52f98276-6ef7-4f2b-bfe2-8f3333cf5d7b@github.com>

On Mon, 2 Feb 2026 13:25:49 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

>> Suchita Chaturvedi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixing spotless failure
>
> core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/security/CryptoUtil.java line 111:
> 
>> 109: 	}
>> 110: 
>> 111: 	public static String getCryptoIcon(
> 
> Splitting up the determination of the severity level and then deciding at the icon at the end might be cleaner. Perhaps using an enum for the severity level.

Icon is just a string here which will be used later to show the specific icon.

> core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/security/CryptoUtil.java line 168:
> 
>> 166: 	}
>> 167: 
>> 168: 	public static String getCryptoRuleResult(
> 
> There is a lot of code duplication. How about separating out some of the key functionality, e.g. :
> 
>   private static boolean isWeakSignatureAlgorithm(String signatureAlgorithm) {                                                                                           
>       return signatureAlgorithm.contains("MD2") || signatureAlgorithm.contains("MD5");                                                                                   
>   }

Both MD2 and MD5 have different logics of handling. Hence, i don't think we can merge them together.

-------------

PR Review Comment: https://git.openjdk.org/jmc/pull/686#discussion_r2761172176
PR Review Comment: https://git.openjdk.org/jmc/pull/686#discussion_r2761177352

From schaturvedi at openjdk.org  Tue Feb  3 22:15:00 2026
From: schaturvedi at openjdk.org (Suchita Chaturvedi)
Date: Tue, 3 Feb 2026 22:15:00 GMT
Subject: RFR: 5561: Support for Crypto Events in JMC [v6]
In-Reply-To: <L3Wlpr7zk0rQE9qSVzkTehMZtHUwr141I2ZFjOF0060=.7ceacbf6-67d0-462d-a35e-7d135046ec42@github.com>
References: <L3Wlpr7zk0rQE9qSVzkTehMZtHUwr141I2ZFjOF0060=.7ceacbf6-67d0-462d-a35e-7d135046ec42@github.com>
Message-ID: <wl2BvdCYBuzpvJbeL9AG9ObIMk8YtUwjHCTu3doWLWo=.01b19fcd-7d65-4a2e-9ee2-5db585489fd1@github.com>

> This PR enhances the JMC UI for adding new information related to crypto events: specifically X509CertificateEvent.
> 
> This PR adds a new rule with respect to X509CertificateEvent which provides alert related to expired/expiring certificates and weak signature algorithms or weak key length or key type. The rule gives a basic overview of all the certificate ids which needs action or attention, however complete details are provided as part of a new screen - Security.
> 
> Attaching the screenshots here for better reference:
> 
> Rule Page:
> 
> <img width="362" height="373" alt="image" src="https://github.com/user-attachments/assets/4707e6b2-76be-4b1e-9f32-c6139851d86c" />
> 
> Security Screen Page:
> 
> <img width="959" height="385" alt="image" src="https://github.com/user-attachments/assets/5026e2b7-2754-47bc-a42d-5672f9f087d7" />

Suchita Chaturvedi has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright year in IRule file

-------------

Changes:
  - all: https://git.openjdk.org/jmc/pull/686/files
  - new: https://git.openjdk.org/jmc/pull/686/files/a4ac49c4..a662ab0e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jmc&pr=686&range=05
 - incr: https://webrevs.openjdk.org/?repo=jmc&pr=686&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jmc/pull/686.diff
  Fetch: git fetch https://git.openjdk.org/jmc.git pull/686/head:pull/686

PR: https://git.openjdk.org/jmc/pull/686

From schaturvedi at openjdk.org  Tue Feb  3 22:26:28 2026
From: schaturvedi at openjdk.org (Suchita Chaturvedi)
Date: Tue, 3 Feb 2026 22:26:28 GMT
Subject: RFR: 5561: Support for Crypto Events in JMC [v7]
In-Reply-To: <L3Wlpr7zk0rQE9qSVzkTehMZtHUwr141I2ZFjOF0060=.7ceacbf6-67d0-462d-a35e-7d135046ec42@github.com>
References: <L3Wlpr7zk0rQE9qSVzkTehMZtHUwr141I2ZFjOF0060=.7ceacbf6-67d0-462d-a35e-7d135046ec42@github.com>
Message-ID: <d5cAwkmxLAbMm_YReSgWtP8Ei7i786UzZz4wjJMUQio=.fd2deb62-e754-418e-bc1b-88ac39dedb46@github.com>

> This PR enhances the JMC UI for adding new information related to crypto events: specifically X509CertificateEvent.
> 
> This PR adds a new rule with respect to X509CertificateEvent which provides alert related to expired/expiring certificates and weak signature algorithms or weak key length or key type. The rule gives a basic overview of all the certificate ids which needs action or attention, however complete details are provided as part of a new screen - Security.
> 
> Attaching the screenshots here for better reference:
> 
> Rule Page:
> 
> <img width="362" height="373" alt="image" src="https://github.com/user-attachments/assets/4707e6b2-76be-4b1e-9f32-c6139851d86c" />
> 
> Security Screen Page:
> 
> <img width="959" height="385" alt="image" src="https://github.com/user-attachments/assets/5026e2b7-2754-47bc-a42d-5672f9f087d7" />

Suchita Chaturvedi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - Merge branch 'openjdk:master' into 5561
 - Update copyright year in IRule file
 - Implemented review comments
 - Fixing spotless failure
 - Merge master
 - Implemented review comments
 - 5561: Support for Crypto Events in JMC

-------------

Changes: https://git.openjdk.org/jmc/pull/686/files
  Webrev: https://webrevs.openjdk.org/?repo=jmc&pr=686&range=06
  Stats: 1490 lines in 33 files changed: 1468 ins; 0 del; 22 mod
  Patch: https://git.openjdk.org/jmc/pull/686.diff
  Fetch: git fetch https://git.openjdk.org/jmc.git pull/686/head:pull/686

PR: https://git.openjdk.org/jmc/pull/686

From schaturvedi at openjdk.org  Tue Feb  3 22:40:42 2026
From: schaturvedi at openjdk.org (Suchita Chaturvedi)
Date: Tue, 3 Feb 2026 22:40:42 GMT
Subject: RFR: 5561: Support for Crypto Events in JMC [v8]
In-Reply-To: <L3Wlpr7zk0rQE9qSVzkTehMZtHUwr141I2ZFjOF0060=.7ceacbf6-67d0-462d-a35e-7d135046ec42@github.com>
References: <L3Wlpr7zk0rQE9qSVzkTehMZtHUwr141I2ZFjOF0060=.7ceacbf6-67d0-462d-a35e-7d135046ec42@github.com>
Message-ID: <is1msWeNdjJ0zNVfq5FJdrsFWEW_wts73yq7NK2h8AM=.bde3f9ce-0ad4-4c36-9418-450c58996d0e@github.com>

> This PR enhances the JMC UI for adding new information related to crypto events: specifically X509CertificateEvent.
> 
> This PR adds a new rule with respect to X509CertificateEvent which provides alert related to expired/expiring certificates and weak signature algorithms or weak key length or key type. The rule gives a basic overview of all the certificate ids which needs action or attention, however complete details are provided as part of a new screen - Security.
> 
> Attaching the screenshots here for better reference:
> 
> Rule Page:
> 
> <img width="362" height="373" alt="image" src="https://github.com/user-attachments/assets/4707e6b2-76be-4b1e-9f32-c6139851d86c" />
> 
> Security Screen Page:
> 
> <img width="959" height="385" alt="image" src="https://github.com/user-attachments/assets/5026e2b7-2754-47bc-a42d-5672f9f087d7" />

Suchita Chaturvedi has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright for datadog as well

-------------

Changes:
  - all: https://git.openjdk.org/jmc/pull/686/files
  - new: https://git.openjdk.org/jmc/pull/686/files/547c384f..bb626491

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jmc&pr=686&range=07
 - incr: https://webrevs.openjdk.org/?repo=jmc&pr=686&range=06-07

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jmc/pull/686.diff
  Fetch: git fetch https://git.openjdk.org/jmc.git pull/686/head:pull/686

PR: https://git.openjdk.org/jmc/pull/686

From duke at openjdk.org  Wed Feb  4 01:48:41 2026
From: duke at openjdk.org (youngledo)
Date: Wed, 4 Feb 2026 01:48:41 GMT
Subject: RFR: 8490: Include numeric types without Persister in
 "Add Filter from Attribute" menu [v6]
In-Reply-To: <KvWGp_qdylhVNgyGRtbyGsVU8CgukBd2jZypNuRoXAQ=.757886d0-d5fc-4552-9ebd-a46f5ea6a90d@github.com>
References: <KvWGp_qdylhVNgyGRtbyGsVU8CgukBd2jZypNuRoXAQ=.757886d0-d5fc-4552-9ebd-a46f5ea6a90d@github.com>
Message-ID: <JfzFJSsVY1Dq1Bq8-nGTNtwT1rEKQ4R2JnQy0wMN-K8=.b5ec22fb-e9d5-496f-8675-c2756a642055@github.com>

> ### Problem
> 
>   Attributes with numeric ContentTypes that don't have a Persister (such as primitive types: byte, short, int, long, float, double, char) are
>   excluded from the "Add Filter from Attribute" context menu in the Event Browser's filter editor.
> 
> #### Steps to reproduce:
>   1. Open a JFR file containing events with primitive numeric fields (e.g., Spring Framework's FlightRecorderStartupEvent with long eventId and
>   long parentId)
>   2. In Event Browser, right-click on a column ? Select "Show Filter"
>   3. Right-click on the filter area ? Select "Add Filter from Attribute"
>   4. Expected: All filterable attributes should appear in the menu
>   5. Actual: Primitive numeric type attributes are missing from the menu
> 
> <img width="2420" height="1362" alt="image" src="https://github.com/user-attachments/assets/70bcb795-7a7b-42f0-a83e-e34cb8e50361" />
> 
> #### Root Cause
> 
>   The getPersistableAttributes() method in DataPageToolkit.java (line 1006-1007) filters attributes based on whether their ContentType has a
>   Persister:
> 
>   ```java
>   .filter(a -> a.equals(JfrAttributes.EVENT_TYPE) || (a.getContentType() instanceof RangeContentType)
>       || (a.getContentType().getPersister() != null))
>   ```
> 
>   However, primitive numeric types use these ContentTypes which don't have a Persister:
>   - UnitLookup.RAW_NUMBER - used by all primitive numeric types (byte, short, int, long, float, double, char)
>   - UnitLookup.RAW_LONG - used by some custom Long attributes
>   - UnitLookup.COUNT, UnitLookup.INDEX, UnitLookup.IDENTIFIER - legacy numeric types
> 
>   These types return null from getPersister() (see ContentType.java:99-101), causing them to be filtered out.
> 
> ### Why this is incorrect:
> 
>   Even though these types cannot be persisted to strings, they fully support filtering via ItemFilters.equals(). Excluding them from the filter
>   menu is inconsistent with their actual capabilities.
> 
> ### Solution
> 
>   Add a helper method isFilterableNumericType() to identify numeric ContentTypes that support filtering even without a Persister, and include them
>    in the filter:
> 
> private static boolean isFilterableNumericType(IAttribute<?> attribute) {
>       org.openjdk.jmc.common.unit.ContentType<?> ct = attribute.getContentType();
>       return ct.equals(UnitLookup.RAW_NUMBER) || ct.equals(UnitLookup.RAW_LONG)|| ct.equals(UnitLookup.COUNT) || ct.equals(UnitLookup.INDEX)
>               || ct.equals(UnitLookup.IDENTIFIER);
>   }
> 
> 
> Update the filter condition to include these types:
> 
>   .filter(a -> a.equals(...

youngledo has updated the pull request incrementally with one additional commit since the last revision:

  Restore .classpath files required for Eclipse IDE development
  
  This commit restores the .classpath files that were previously removed.
  These files are essential for JMC development in Eclipse IDE due to the
  project's hybrid nature as both a Maven and PDE/OSGi application.

-------------

Changes:
  - all: https://git.openjdk.org/jmc/pull/699/files
  - new: https://git.openjdk.org/jmc/pull/699/files/271713e9..6510b3bd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jmc&pr=699&range=05
 - incr: https://webrevs.openjdk.org/?repo=jmc&pr=699&range=04-05

  Stats: 3290 lines in 131 files changed: 3290 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jmc/pull/699.diff
  Fetch: git fetch https://git.openjdk.org/jmc.git pull/699/head:pull/699

PR: https://git.openjdk.org/jmc/pull/699

From duke at openjdk.org  Wed Feb  4 01:48:42 2026
From: duke at openjdk.org (youngledo)
Date: Wed, 4 Feb 2026 01:48:42 GMT
Subject: RFR: 8490: Include numeric types without Persister in
 "Add Filter from Attribute" menu [v5]
In-Reply-To: <01YA0glXqS8oySF-nvQSfn_26GRHd12V6QPilEVugmw=.b1e2983a-66dd-458a-adb1-8ac109edca4a@github.com>
References: <KvWGp_qdylhVNgyGRtbyGsVU8CgukBd2jZypNuRoXAQ=.757886d0-d5fc-4552-9ebd-a46f5ea6a90d@github.com>
 <WQnyGWty6e6H8VtA_WUPOVQbmYoSq0_AyJxgxNx0W7k=.f54386e9-2f53-4db4-8ad7-d8eef1b7b1f4@github.com>
 <01YA0glXqS8oySF-nvQSfn_26GRHd12V6QPilEVugmw=.b1e2983a-66dd-458a-adb1-8ac109edca4a@github.com>
Message-ID: <WPvuus2qmawnP8sBNq3sWfCyJ6vdQrmSDIQbCYNXmO8=.1379169b-e2c2-4654-a663-cb090bde278c@github.com>

On Tue, 3 Feb 2026 18:07:13 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

> Will the removal of the .classpath files cause any trouble running JMC from within the Eclipse development environment? I am not perfectly sure, but I have a faint memory of a few of them being slightly specialized.

Thank you for the reminder, I have recovered.

-------------

PR Comment: https://git.openjdk.org/jmc/pull/699#issuecomment-3844769618

From duke at openjdk.org  Wed Feb  4 02:02:04 2026
From: duke at openjdk.org (youngledo)
Date: Wed, 4 Feb 2026 02:02:04 GMT
Subject: RFR: 8490: Include numeric types without Persister in
 "Add Filter from Attribute" menu [v7]
In-Reply-To: <KvWGp_qdylhVNgyGRtbyGsVU8CgukBd2jZypNuRoXAQ=.757886d0-d5fc-4552-9ebd-a46f5ea6a90d@github.com>
References: <KvWGp_qdylhVNgyGRtbyGsVU8CgukBd2jZypNuRoXAQ=.757886d0-d5fc-4552-9ebd-a46f5ea6a90d@github.com>
Message-ID: <rNjBIITeakIMMuTNoPric6DsrLvPq9Y28fd7yZtEYEY=.e08145aa-a0d8-467f-9f9a-c91bd624bb34@github.com>

> ### Problem
> 
>   Attributes with numeric ContentTypes that don't have a Persister (such as primitive types: byte, short, int, long, float, double, char) are
>   excluded from the "Add Filter from Attribute" context menu in the Event Browser's filter editor.
> 
> #### Steps to reproduce:
>   1. Open a JFR file containing events with primitive numeric fields (e.g., Spring Framework's FlightRecorderStartupEvent with long eventId and
>   long parentId)
>   2. In Event Browser, right-click on a column ? Select "Show Filter"
>   3. Right-click on the filter area ? Select "Add Filter from Attribute"
>   4. Expected: All filterable attributes should appear in the menu
>   5. Actual: Primitive numeric type attributes are missing from the menu
> 
> <img width="2420" height="1362" alt="image" src="https://github.com/user-attachments/assets/70bcb795-7a7b-42f0-a83e-e34cb8e50361" />
> 
> #### Root Cause
> 
>   The getPersistableAttributes() method in DataPageToolkit.java (line 1006-1007) filters attributes based on whether their ContentType has a
>   Persister:
> 
>   ```java
>   .filter(a -> a.equals(JfrAttributes.EVENT_TYPE) || (a.getContentType() instanceof RangeContentType)
>       || (a.getContentType().getPersister() != null))
>   ```
> 
>   However, primitive numeric types use these ContentTypes which don't have a Persister:
>   - UnitLookup.RAW_NUMBER - used by all primitive numeric types (byte, short, int, long, float, double, char)
>   - UnitLookup.RAW_LONG - used by some custom Long attributes
>   - UnitLookup.COUNT, UnitLookup.INDEX, UnitLookup.IDENTIFIER - legacy numeric types
> 
>   These types return null from getPersister() (see ContentType.java:99-101), causing them to be filtered out.
> 
> ### Why this is incorrect:
> 
>   Even though these types cannot be persisted to strings, they fully support filtering via ItemFilters.equals(). Excluding them from the filter
>   menu is inconsistent with their actual capabilities.
> 
> ### Solution
> 
>   Add a helper method isFilterableNumericType() to identify numeric ContentTypes that support filtering even without a Persister, and include them
>    in the filter:
> 
> private static boolean isFilterableNumericType(IAttribute<?> attribute) {
>       org.openjdk.jmc.common.unit.ContentType<?> ct = attribute.getContentType();
>       return ct.equals(UnitLookup.RAW_NUMBER) || ct.equals(UnitLookup.RAW_LONG)|| ct.equals(UnitLookup.COUNT) || ct.equals(UnitLookup.INDEX)
>               || ct.equals(UnitLookup.IDENTIFIER);
>   }
> 
> 
> Update the filter condition to include these types:
> 
>   .filter(a -> a.equals(...

youngledo 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 17 additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into event-browser-menu
 - Restore .classpath files required for Eclipse IDE development
   
   This commit restores the .classpath files that were previously removed.
   These files are essential for JMC development in Eclipse IDE due to the
   project's hybrid nature as both a Maven and PDE/OSGi application.
 - Update copyright year to 2026
 - Remove .claude/settings.local.json from version control
   
   This file should not be tracked as it contains local settings.
   Added .claude/ to .gitignore to prevent future commits.
   
   Co-Authored-By: Claude Sonnet 4.5 <noreply at anthropic.com>
 - 8527: Add AGENTS.md file
   
   Reviewed-by: aptmac
 - 8512: Fixing various minor typos and nits
   
   Reviewed-by: aptmac, clanger
 - 8526: Update third parties for 10.0.0
   
   Reviewed-by: aptmac
 - 8479: Update jolokia third party for JMC 10.0.0
   
   Reviewed-by: schaturvedi
 - 8489: Inaccurate Chinese translations on TLAB page
   
   Reviewed-by: aptmac
 - Fix: Add proper error handling for empty input in numeric filters
   
   Modified both UnitLookup and CommonCellEditors to properly handle empty or invalid
   input when editing numeric type filters, preventing "Unhandled event loop exception" errors.
   
   Changes:
   1. UnitLookup.java:
      - Added try-catch blocks to parsePersisted() and parseInteractive() methods
      - Catch NumberFormatException and throw IllegalArgumentException with clear message
      - Applied to RAW_NUMBER, RAW_LONG, COUNT, INDEX, and IDENTIFIER types
   
   2. CommonCellEditors.java:
      - Added catch block for IllegalArgumentException and NumberFormatException
      - Displays error message in UI when user enters invalid value
      - Prevents unhandled exception from crashing the UI
   
   This ensures a user-friendly experience when editing numeric filters, especially
   when clearing input fields.
   
 - ... and 7 more: https://git.openjdk.org/jmc/compare/4ccc0926...2a33d0e5

-------------

Changes:
  - all: https://git.openjdk.org/jmc/pull/699/files
  - new: https://git.openjdk.org/jmc/pull/699/files/6510b3bd..2a33d0e5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jmc&pr=699&range=06
 - incr: https://webrevs.openjdk.org/?repo=jmc&pr=699&range=05-06

  Stats: 1609 lines in 31 files changed: 1162 ins; 409 del; 38 mod
  Patch: https://git.openjdk.org/jmc/pull/699.diff
  Fetch: git fetch https://git.openjdk.org/jmc.git pull/699/head:pull/699

PR: https://git.openjdk.org/jmc/pull/699

From aptmac at openjdk.org  Wed Feb  4 14:34:40 2026
From: aptmac at openjdk.org (Alex Macdonald)
Date: Wed, 4 Feb 2026 14:34:40 GMT
Subject: RFR: 6872: Add butterfly/sandwich view to JMC [v2]
In-Reply-To: <Oe8qfs0RK0QxPjAHeCjKJ7XfbG0FblzbBneSn7ifdkE=.c6229c19-fbbb-45c0-8535-e481d73006c1@github.com>
References: <CQqXPKjH5xhYak1TQF6W2qgzpvA2mXokzRjIAbhyIg0=.583fc635-175c-4841-b08b-07fb96daf64e@github.com>
 <Oe8qfs0RK0QxPjAHeCjKJ7XfbG0FblzbBneSn7ifdkE=.c6229c19-fbbb-45c0-8535-e481d73006c1@github.com>
Message-ID: <kKhKWL05S7GzUVhuSm7dYeiyz9ehEz4zqQ1vpcXT7X8=.769e9035-3036-46d8-98b6-c013b79f0e37@github.com>

On Mon, 8 Dec 2025 20:20:47 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

>> This PR adds a butterfly (aka sandwich) view to JMC, showing all the callers and callees for a selected method. 
>> 
>> <img width="2548" height="1224" alt="buttefly" src="https://github.com/user-attachments/assets/ad3d33d8-944b-49d6-be98-62444f11da93" />
>> 
>> Also fixes annoying spelling error.
>
> Marcus Hirt has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Spotbugs fix

Marked as reviewed by aptmac (Reviewer).

-------------

PR Review: https://git.openjdk.org/jmc/pull/693#pullrequestreview-3751413321