Remko Popma

I am cleaning up old tickets. I don't think there is any work remaining on this ticket, so I will close it. Thank you for raising this!

See https://stackoverflow.com/questions/69688720/using-picocli-with-picocli-shell-jline3-and-configured-java-modules-leads-to-unn

Can you try making the annotated fields `protected` instead of `private`?

Can you show your class and the generated `reflect.json`?

> Could this be related to programmatically registering the commands and subcommands (based on the idea in Bottom-up sub-commands declaration #1442), rather than declaratively? Yes definitely. The annotation processor only...

If superclasses have picocli annotations then those superclasses should also be included in the `reflect.json` generated by the annotation processor. Are you saying that this is not the case?

I was able to reproduce the issue in a unit test. Investigating now...

Hmm... this may be a problem caused by incremental compilation. In my test, if I only compile the concrete subclass, then the generated `reflect-config.json` contains only entries for that class....

If the superclass is in a separate Gradle module, then one idea is to generate a separate `reflect-config.json` for that module, by specifying the annotation processor for that module also....

Thanks for raising this! My position has always been to support Java 5 as long as possible. This is a new argument against that, that is good to know. It...