Sorry, but that's ridiculous, you need to break that sub up into smaller more manageable subs.
I have in this Sub Select Case with 100 cases.
I have split the last 20 Cases in a separate sub . Its OK.
Java shouldn't be needlessly imposing limits, but it does, and you've hit one, so Peter's right, now you need to break that sub up. Such is life.
It sounds like you are splitting your Select Case into groups, which should work fine.
Another approach is data-driven programming*, which is where whenever you have lots of repeats of similar looking code, you store the changing bits into an array (probably loaded from a file) or database, and then just have one bit of general code that uses the entry applicable to the currently Selected Case.
Eg I took over maintenance of a program that had all the screen input logic hardcoded into the program. Each field had like 40 lines of code, all of it similar except for the specifics of the field. I moved all the screen field attributes (
line, column, length, color, alignment, type, minimum, maximum, filter, must-be-upper-case, trim-spaces, can-be-empty, previous field, next field, enter field, up field, down field, left field, right field) into an array, and then wrote a single screen input routine that used that info to handle data entry without repeating code for each and every field. Program halved in size, and my workload of fixing screen input anomalies just evaporated completely.
Better yet, whenever I made an improvement (or bug fix
) to the general routine (eg, adding pop-up extra info when entering dates) that improvement was then available on all of the ~150 input screens, without me having to go through 150 separate pieces of code.
The previous programmer was a brilliant guy, but $#@! he made life hard for himself.
* at least, that's what we called it last century, it probably has a trendier name now