[4.35+] Modernize CodeStream hierarchy by collapsing the hierarchy

[srikanth-sankaran]

In the post 1.8+ only world, it makes no sense anymore to have a hierarchy of TypeAnnotationCodeStream <: StackMapFrameCodeStream <: CodeStream.
Collapsing them into one, just CodeStream would make maintenance much easier.

Rather than help, these just obfuscate.

[stephan-herrmann]

I'm not sure I agree here.

At least TypeAnnotationCodeStream looks useful to me, not because we need flexibility in creating instances with different capabilities, but for simple separation of concerns: CodeStream doesn't bother at all about type annotations. Isn't that worth preserving?

For StackMapFrameCodeStream the picture is indeed a bit blurred. Perhaps we could try to establish the following rule: this class should be responsible for exactly all stuff that relates to its own fields stateIndexes, stateIndexesCounter, framePositions, exceptionMarkers, stackDepthMarkers, stackMarkers. Code that operates only on state of the super class can be pulled up / integrated with super methods. To avoid copy-paste overrides, we could introduce abstract methods in CodeStream as hooks for StackMapFrameCodeStream, so CodeStream may invoke but not implement stackmap functionality. Perhaps this alone will yield the clean-up you are striving for?

[srikanth-sankaran]

Perhaps this alone will yield the clean-up you are striving for?

I don't know what I am striving for - This is just a place holder so I have a task in my radar. Your input above will certainly will be useful when I do get cycles for this. Thanks

[srikanth-sankaran]

Perhaps this alone will yield the clean-up you are striving for?

I don't know what I am striving for - This is just a place holder so I have a task in my radar. Your input above will certainly will be useful when I do get cycles for this. Thanks

(I admit my description in comment#0 sounds much more definitive than intended)