Another thought would be to convert this code-based design to a data-driven
approach. Would an in memory database or a JSON/XML resource file be a better
place to represent and store the 1200+ entities?
-----Original Message-----
From: Milles, Eric (TR Technology)
Sent: Saturday, February 25, 2023 9:43 AM
To: dev@groovy.apache.org
Subject: RE: [EXT] Workaround for large enum throwing MethodTooLargeException ?
These are workaround ideas, so please excuse the design choices.
// anonymous inner approach
enum E {
A() {
final String thing = "DEV_PR"
// add read-only properties or getter methods for Type1.M2, Type1.DEVELOPER,
"Progr", "Programmer", [cat.WHITE_COLLAR, cat.PROPELLERHEAD]
},
B() {
final String thing = "value for B"
},
...;
abstract String getThing()
// abstract getter methods for each property you want to expose }
enum E {
A, B, C ... Z;
// switch-based approach
String getThing() {
switch (this) {
case A:
return "DEV_PR"
case B:
return "value for B"
}
}
// map-based approach -- each property could be moved to a separate class if
space or verbosity is a concern
private static Map<E,String> THINGS = new EnumMap(E) // inline map literal
may be possible here instead of "E" and static puts below
static {
// these could be divided into several static methods if the initializer
gets too long
THINGS.put(A,"DEV_PR")
...
}
String getThing() {
THINGS.get(this)
}
}
Sorry, no idea if in your case any of these also run into method too large
exceptions. And for the switch or map-based approaches, you could make
"getThing()" a static method in some separate class or an extension method so
you can access it like it is part of the enum constant instances.
In terms of the root cause, can you share the bytecode for the initializer up
through the first 2 or 3 enum constants? We may be able to make it more
efficient. And in the case of large enums, break it up into separate methods.
Not sure how javac handles this and what the ultimate upper limit is for enum
constants.
