when using "superclass for generated code, subclass to enhance/override behaviour" - concept, then generated, nested "final" types are _evil_!
The types should not be in the abstract base class, but on the acutal class the API user will use. but this class is not being generated (only inhertis the generated class) but types are not being inherited, nor can you subclass them into the subclass because they are final.
introduced an AbstractMessage base class (for the generated parts), to be extended into Message (there we can enhance ond override the generated code). Works, only problem is the enum types that are being generated into the Message class... e.g. Message.EncType, Message.Direction. These of course are now in AbstractMessage.EncType etc.. and thats of course not good.
but because they are generated they cant be in the Message class, so at the moment having copies of these types in Message.java... Like this everything works, but of course it needs a design solution.
Of course the plan then is to add the Message.toXER() method in Message.java as non-generated code (because it cant really be generated because of the "compound" nature of the function being approx: is msg encrypted, then decrypt with 0x200 flag, then getAttachement(0), if sync msg Sync::PER_to_XER else distribution::PER_toXER(), return.)
in accordance with JNI-84 Reverse hierarchy of Engine and AbstractEngine.
heck