GraalVM: Options from superclass not visible #1444
Comments
|
Can you try making the annotated fields |
Thanks, I'll try that and let you know the results. In the meantime I did try using the default access modifier together with Micronauts
|
Tried making all relevant option & mixin fields protected, but unfortunately those options are still not being recognized by picocli when running in GraalVM native image. I also noticed that for example |
|
Can you show your class and the generated |
|
(Edited) In the meantime I've been able to make this work by declaring Micronaut's It does seem a bit cumbersome though having to annotate almost every picocli-related class with So although this is working now, I still have some questions:
Thanks! |
Yes definitely.
Recently I have very little time to spend on picocli, so if there is a workaround then let's go with that. |
|
Looking somewhat closer at this, I seems like picocli is including Manually adding |
|
If superclasses have picocli annotations then those superclasses should also be included in the |
|
Depends on what you mean with 'if superclasses have picocli annotations'; the class itself doesn't have any picocli annotations but the fields do. See example below. Base class: @ReflectiveAccess
public abstract class AbstractSessionLoginCommand<C> extends AbstractCommandWithLoginSessionHelper implements Runnable {
@ArgGroup(heading = "Optional login session name:%n", order = 1000)
@Getter protected LoginSessionNameOptions loginSessionNameOptions;
private static class LoginSessionNameOptions {
@Option(names = {"--login-session-name", "-n"}, required = false, defaultValue = "default")
@Getter protected String loginSessionName;
}
...@Singleton @ReflectiveAccess
@SubcommandOf(SessionLoginRootCommand.class)
@Command(name = "dummy", description = "Login to MySystem", sortOptions = false)
public class MyLoginCommand extends AbstractSessionLoginCommand<MyConnectionConfig> {
@ArgGroup(exclusive = false, multiplicity = "1", heading = "Connection options:%n", order = 1)
@Getter private LoginConnectionOptions connectionOptions;
...In the resulting jar file, Current work-around is to add the |
remkop
added
theme: annotation-proc
|
I was able to reproduce the issue in a unit test. |
|
Hmm... this may be a problem caused by incremental compilation. In my test, if I only compile the concrete subclass, then the generated I am not sure how to make progress with this. Any ideas? |
|
It's been a while since I last looked at this, but I think the problem was also present when doing a full, clean build. In my case though, the parent class was (most likely) in a separate Gradle module. So, by the time the subclass got compiled, the superclass would have been already compiled by a different javac invocation. I'm not really familiar with all the ins and outs of Java compilation and annotation processors, so I wouldn't really know how to fix something like this. Can the annotation processor use reflection to inspect the superclass and generate the appropriate |
|
If the superclass is in a separate Gradle module, then one idea is to generate a separate To answer your question, yes I think it’s theoretically possible to climb the class hierarchy and inspect all child elements (and nested grandchild elements of the child elements, recursively) for picocli annotations. But that’s kind of what the annotation processor API is supposed to do for us. It appears to be a lot of work for something that should already be working: the annotation processor should already get callbacks for each picocli-annotated element in the superclass. |
|
@remkop, some new information on this issue:
For reference, the classes listed below are missing from Any idea why this is happening? |
|
Are you doing |
|
Both clean and incremental builds show the same behavior. We normally build native binaries only from our GitHub Actions workflow, with a clean workspace, and the missing |
|
Are these abstract superclasses marked with the |
I have an abstract base command class that defines an ArgGroup as follows:
This base class is extended by an actual command class, defining some additional options or argument groups. When running as a normal jar file (or from within my IDE), all options from both base class and actual command class are properly recognized by Picocli.
However, when running as a GraalVM native image, Picocli doesn't recognize the options defined in the abstract base class; they do not show up in the help output, and you get an 'Unknown option' error when trying to use these options from the base class.
A similar issue can be seen with argument group classes that extend from some other class (also if the base class is not abstract). In the following example, again the options from MyArgGroupNonAbstractBaseClass are not recognized in the native image:
Any idea on how this can be fixed?
The text was updated successfully, but these errors were encountered: