RFR: Refactored new ToolInput/Outputs so they reside in own packages and not in original interfaces

[Jiří Vaněk]

On Tue, 3 Jan 2023 15:47:00 GMT, Jiří Vaněk <jvanek at openjdk.org> wrote:

>> This PR is refactoring the long interfaces with many inner classes to logical packages.
>
> As promised earlier. I'm still hesitating with the usage of uEscWriter in string based inputs/outputs. Maybe do you have jasm/jdis class reproducer of possible issues?

> @judovana How much is it useful is refactor the code like this? Some of the refactored classes are very small. How much 

They were originally placed in only two classes - in the top level directories themselves, as the number of resulting types was underestimated. The interface' java files had 500 lines+ and 7+ named inner clasess, where each was necessary to use for different usecase. 
I myself, as author of those classes, had to look half year later to the interface, and search for the implementation names. As they are now, you look into pakcage, and directly knows.

>do the subtypes have subtype-specific API that needs to be directly and publicly available, compared to methods that just implement or override behavior declared in the super type.

Thy do. Mos tof the implementations is 50-100 lines, and overwirte the mai work methods -  getDataInputStream for input and startclass/finshclass  for outputs.

> 
> Would it be better to just hide the subtypes where possible, and have static factory methods in the supertypes, possibly setting up the use of sealed classes and `permits` down the road?

Maybe. But I woudl rather have it opened as much as possible.
The main asmtool methods are allowng you to use any implementation of ToolInput/Output/Log which you desire.
The asmtools application itself, is using stdin/printout or  filein/dirout. Usage if asmtools as libraryand thus base for future IDE (and asmtools' unittests)  is mostly going to use  stringin/streamin/bytein and stringout/byteout 

I think the freedom to deal with input/output in flexible way is crucial for asmtool to have more chances to catch up as more widely used language/library, as it already now allowed to be more easy to use as cli tool.

-------------

PR: https://git.openjdk.org/asmtools/pull/53