[GitHub] [jmeter] vlsi opened a new issue, #5895: Split JMeterGUIComponent into metadata and UI parts

[via GitHub]

vlsi opened a new issue, #5895:
URL: https://github.com/apache/jmeter/issues/5895

   ### Use case
   
   Currently, `JMeterGUIComponent` mixes several responsibilities:
   1) Create and serve UI
   2) Provide metadata on the component: `#getStaticLabel`, 
`#getLabelResource`, `#getDocAnchor`, `#getMenuCategories`
   
   JMeter, needs to build menus on the startup, so it needs to discover 
elements, their labels, and the categories.
   Unfortunately, most implementations create UI elements in their 
constructors, so it would take a lot of time if JMeter instantiated all 
`JMeterGUIComponents` on the startup.
   
   Instantiating the UI in the constructor blocks migration to `ServiceLoader` 
approach for component lookup as `ServiceLoader` always instantiates the 
services.
   
   See https://github.com/apache/jmeter/pull/5885
   
   ### Possible solution
   
   ## a) Split "metadata" part into a different interface.
   
   For instance:
   
   ```java
   /**
    * Metadata for JMeter GUI components.
    */
   interface GuiComponentRegistration {
       Class<?> implementationClass();
       String labelResource();
       default String resourceBundle() {
           return "";
       }
       default List<String> actionGroups() {
           return Collections.emptyList();
       }
   }
   
   // Sample component implementation
   
   @AutoService(GuiComponentRegistration.class)
   class WhileControllerComponentRegistration implements 
GuiComponentRegistration {
       @Override
       public Class<?> implementationClass() {
           return WhileControllerGui.class;
       }
   
       @Override
       public String labelResource() {
           return "while_controller_title";
       }
   }
   ```
   
   The implementation `WhileControllerGui` could delegate 
`WhileControllerGui#labelResource` to `WhileControllerComponentRegistration` 
service.
   
   For instance, we could add 
`AbstractJMeterGuiComponent#setMetadata(GuiComponentRegistration)` method, and 
we could provide default implementations of 
`AbstractJMeterGuiComponent#labelResource`.
   
   Yet another possibility is to add 
`AbstractJMeterGuiComponent(GuiComponentRegistration)` constructor and 
deprecate the old one. That would enable detecting non-migrated code at the 
compile time.
   
   ## b) Move UI instantiation out of constructors
   
   An alternative option is to move `init()` methods out of constructors and 
add the `JMeterGUIComponent#createUI` method to create all the UI components 
when needed.
   
   I am not sure that would work well:
   * `class AbstractJMeterGuiComponent extends JPanel`, so it would trigger 
`JPanel` instantiation in any case, so it would impact the startup time
   * It would be impossible to use `private final JTextArea commentField =...` 
fields. Code complexity would increase as it would have to use nullable fields
   
   ### Possible workarounds
   
   _No response_
   
   ### JMeter Version
   
   5.5
   
   ### Java Version
   
   _No response_
   
   ### OS Version
   
   _No response_


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@jmeter.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org