Unsupported class file version reduced to warning once

[errt]

In order to reduce visual clutter and usually irrelevant information (most times, OPAL works reasonably well with newer Java versions), this PR

• reduces the message on unsupported class file versions to a warning instead of an error
• logs these messages only once instead of for each class file with an unsupported version
  and adds additional information to the message.

We could discuss whether we want to do only one of these reductions in order to not make unsupported class file versions too likely to be unnoticed. Another option would be to reduce the clutter only for, e.g., one major version beyond the known support and have a stronger warning if OPAL is outdated more severely.

[maximilianruesch]

As you stated, newer Java versions are reasonably well supported out of the gate by OPAL, so reducing from an error to a warning is okay (also considering that the analyses still continue to run, and do not abort). Adding additional information is also reasonable to make the previous clear, and in its current state the message does not provide the class it uses, so is unique and thus logging it once is also okay.

Imo logging the exact same message twice is just clutter, no additional information. If something is so important that it needs to be noticed by the user, we should employ different strategies. I propose that we add a --safe (or --unsafe, or similar) option to OPAL, that allows / disallows parsing unsupported class file versions. In the default, it should be disallowed, so the user has to make a conscious choice to allow such class files, in which case they are already aware enough to "just" receive a warning.

Additionally, the problem of the message not mentioning which class files have an unsupported version remains. Perhaps in most cases all class files are compiled with the same version (I don't know whether the JVM even allows running mixed versions at the same time). If that is not the case, we should think to add a small command that lists all unsupported class files in your project.

[johannesduesing]

I agree that "Warning" is the appropriate log level for this message, since - as you already stated - most analyses will continue to run as they would for other class file versions. I also think logging it just once is the way to go.

I do think that we should try to collect the names of all class files that have unsupported version numbers and add them (or the first N instances) to the warning message - i do not think the message is very actionable if it does not point to specific class files.

[errt]

Collecting the first n classes before issuing the warning is not possible. At no time would we know that there will be more (or no more) class files with unsupported versions.
Also, adding anything dynamic to the message would counteract the logOnce which works by remembering which messages have been issued before.

@maximilianruesch Yes, the JVM allows class files of arbitrary (earlier) versions to be executed together. AFAIK, the JDK still contains files that have not been recompiled since Java 1.1.