[jboss-jira] [JBoss JIRA] (WFLY-1415) Move away from expensive enum switch

[Brian Stansberry (Jira)]

    [ https://issues.redhat.com/browse/WFLY-1415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14027532#comment-14027532 ] 

Brian Stansberry edited comment on WFLY-1415 at 4/8/20 1:29 PM:
----------------------------------------------------------------

[~lvydra]. I think this is still valid.  I think it is too broadly scoped though, so any work should be done via more narrow subtasks with a separate JIRA per subtask.

I see a number of general *categories* of subtasks, with each category often involving distinct subtask JIRAs:

1) Subsystems in WildFly Core that do not use PersistentResourceXMLParser/PersistentResourceXMLDescription for their parsing. At a glance I think that's deployment-scanner, jmx, logging, remoting, maybe threads.  I think a place to start is with one or more of these (not threads at first). You could contact the lead for the component (https://issues.redhat.com/projects/WFCORE?selectedItem=com.atlassian.jira.jira-projects-plugin:components-page), check with them and then file a subtask WFCORE for that subsystem. One PR per JIRA.

2) Same for subsystems in full WildFly. (I haven't looked which there are.) Those would be tracked with WFLY JIRAs. Lower priority; better to start with WF Core to get familiar while interacting with the WF Core devs, who are more familiar with management code in general. Full WildFly component leads are at (https://issues.redhat.com/projects/WFLY?selectedItem=com.atlassian.jira.jira-projects-plugin:components-page)

3) The kernel parsers in WF Core. (StandaloneXml, HostXml, DomainXml and related classes.). This is a big job and requires careful planning as we wouldn't want to disrupt more critical work. Perhaps it could be divided into smaller less disruptive pieces. Any work would be tracked via a WFCORE.

4) There may be some other misc parsers to eventually look at. Deployment descriptors, CLI config etc.

This seems like something where the best thing is to find subsystems where there isn't much activity (so any change isn't disruptive to other work), and then when you (or others) have some spare time contact the subsystem lead, file a JIRA and get that one done.


was (Author: brian.stansberry):
[~lvydra]. I think this is still valid.  I think it is too broadly scoped though, so any work should be done via more narrow subtasks with a separate JIRA per subtask.

I see a number of general *categories* of subtasks, with each category often involving distinct subtask JIRAs:

1) Subsystems in WildFly Core that do not use PersistentResourceXMLParser/PersistentResourceXMLDescription for their parsing. At a glance I think that's deployment-scanner, jmx, logging, remoting, maybe threads.  I think a place to start is with one or more of these (not threads at first). You could contact the lead for the component (https://issues.redhat.com/projects/WFLY?selectedItem=com.atlassian.jira.jira-projects-plugin:components-page), check with them and then file a subtask WFCORE for that subsystem. One PR per JIRA.

2) Same for subsystems in full WildFly. (I haven't looked which there are.) Those would be tracked with WFLY JIRAs. Lower priority; better to start with WF Core to get familiar while interacting with the WF Core devs, who are more familiar with management code in general.

3) The kernel parsers. (StandaloneXml, HostXml, DomainXml and related classes.). This is a big job and requires careful planning as we wouldn't want to disrupt more critical work. Perhaps it could be divided into smaller less disruptive pieces.

4) There may be some other misc parsers to eventually look at. Deployment descriptors, CLI config etc.

This seems like something where the best thing is to find subsystems where there isn't much activity (so any change isn't disruptive to other work), and then when you (or others) have some spare time contact the subsystem lead, file a JIRA and get that one done.

> Move away from expensive enum switch
> ------------------------------------
>
>                 Key: WFLY-1415
>                 URL: https://issues.redhat.com/browse/WFLY-1415
>             Project: WildFly
>          Issue Type: Task
>            Reporter: David Lloyd
>            Priority: Minor
>              Labels: janitor
>
> We use enums and enum switch extensively.  These constructs generate many, many additional classes and bloat the code base unnecessarily.
> All cases where we are using enum-based switches for our XML parsers should be converted to use Java 7 String switch instead.  The enum values shall be replaced with String constant fields, all enum switches converted to String switches, and all enum types removed from these classes.  The net result should be a reduction by dozens if not hundreds of .class files, and possibly a measurable performance boost as well.



--
This message was sent by Atlassian Jira
(v7.13.8#713008)