Show bytecode version (and implied Java version) to the user

[mkoncek]

This issue was encountered when uploading recompiled bytecode of classes containing nested classes. The class com.google.gson.internal.Streams was compiled for Java 6. Java 11 introduced changes (NestHost / NestMembers). If you recompile this class with flags indicating source version at least 11, it will compile but fail to upload with an error message pointing specifically to NestHost / NestMembers.

It may be a good idea to show the bytecode version in the UI and possibly somehow let the user know that they should be using the same bytecode version.

[judovana]

The version is already visible in byte view, or with both disassemblers. To read it, and suggest it for compilation, already crossed my mind. As yes, it seems to be crucial

[judovana]

pls, any brainstorming on how to do this properly is welcomed. Considering from how many places the compile is called, as lib, as gui, as cli... How to tell user, that he is using bad bytecode version, and that they should use different and that we can set it on theirs behalf (if they wish). In addition, they may have already put it to custom source/target/release in the custom compile flags.

Here is important question - how enforcing we should be? Can the bytecode actuly be changed? Afaik yes, but the risk of what you stumbled over is high.

In gui, it may be config checkbox or popup dialog. In cli.. I'm reluctnat to both cmdline switch (as cli reads config) and stdin question.

To print a warning is definitely a goood start.

[mkoncek]

In order to show it in the error massege, the upload component would have to work with very unrelated information (bytecode version + CPLC flags), while this would work as a reminder, I don't think it is worth the complexity... depends on the userbase of this tool.

What I imagined was that there would be one sentence somewhere in Help or general overview recommending to use the same versions. And on top of that, have a small section in the GUI, where there would be bytecode version + Java version.

But... there is also CLI tool, I don't use it very much, but it should be handled as well. Maybe printing the suggestion message on failed upload isn't a bad idea after all.

[judovana]

Idea how to workaround the source/target/release and even host/local vm versions - once you return the byte[], I can easily read bytecode version from it, and from original(s). If it do not match, the cli will just serr warning. The gui prtobably should warn more loudly.

The gui setup may be done more graphic - like in config enable button to generate source/tareget/release based on current byte view. Cli is reading this setup. It will remain future feature to enable this more comfortably.

Thanx for the ideas.

As for original issue. Using -release XYZ in gui, is solving it?

[mkoncek]

Good idea about comparing versions in old / new bytecodes.

For original issue: setting -source X -target X, for {6 <= X <= 10} the upload works. This really reflects the NestHost / NestMembers added in 11.

[judovana]

bytecode is now propagated to user, who can single click copy it to clipboard. More work is needed, to propagate it dirrectly to compiler. Maybe change the bytecode button to toogle button?

[judovana]

this is fixed in 7. original version is shown and used, unless user says differently