[Bug] [2.5.2] groovy.cli.picocli.CliBuilder.parseFromSpec does not cast its result to the correct type

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[Bug] [2.5.2] groovy.cli.picocli.CliBuilder.parseFromSpec does not cast its result to the correct type

Kevin Perkins
Hello,

I think I've found a bug with groovy.cli.picocli.CliBuilder as of Groovy 2.5.2. I didn't find this particular issue in JIRA. I figured I'd ask here. The parseFromSpec method of groovy.cli.picocli.CliBuilder seems to always return a LinkedHashMap instead of the expected type (the class given as the first argument). The source my IDE shows me for this method has "cliOptions as T" as the last line in the method. I think that the problem is T is erased when the method is compiled and so the "as T" does (effectively) nothing. I think the correct code would be "cliOptions.asType(optionsClass)".

Environment information:
/* -------------- groovy --version ------------------------------------ */
Groovy Version: 2.5.2 JVM: 1.8.0_172 Vendor: Oracle Corporation OS: Windows 7

/* --------------- IDE version info ------------------------------------- */
IntelliJ IDEA 2018.2.3 (Ultimate Edition)
Build #IU-182.4323.46, built on September 3, 2018
JRE: 1.8.0_152-release-1248-b8 amd64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Windows 7 6.1

The following code demonstrates the issue:
/* ------------------------ Begin Example Code ------------------------ */
import groovy.cli.Option
import groovy.cli.picocli.CliBuilder

class CliBuilderBug {
    interface CliArguments {
        @Option(longName='dummy') int dummy()
    }

    static void main(String[] args) {
        CliBuilder builder = new CliBuilder()

        def ok = builder.parseFromSpec(CliArguments, args) as CliArguments
        assert ok instanceof CliArguments // ok
        println "Using 'as' works."

        def notOk = builder.parseFromSpec(CliArguments, args)
        assert notOk instanceof LinkedHashMap // this assertion is true
        assert notOk instanceof CliArguments // fails
        println 'We never get here.'
    }
}
/* ------------------------ End Example Code ------------------------ */

I hope this is helpful, and thank you for your time.
- Kevin Perkins
NOTICE TO RECIPIENT:  If you are not the intended recipient of this e-mail, you are prohibited from sharing, copying, or otherwise using or disclosing its contents.  If you have received this e-mail in error, please notify the sender immediately by reply e-mail and permanently delete this e-mail and any attachments without reading, forwarding or saving them.  Thank you.

Reply | Threaded
Open this post in threaded view
|

Re: [Bug] [2.5.2] groovy.cli.picocli.CliBuilder.parseFromSpec does not cast its result to the correct type

Remko Popma
Kevin, that’s strange, there are working unit tests that do exactly the same...
For example:


On Wed, Sep 12, 2018 at 12:52 Kevin Perkins <[hidden email]> wrote:
Hello,

I think I've found a bug with groovy.cli.picocli.CliBuilder as of Groovy 2.5.2. I didn't find this particular issue in JIRA. I figured I'd ask here. The parseFromSpec method of groovy.cli.picocli.CliBuilder seems to always return a LinkedHashMap instead of the expected type (the class given as the first argument). The source my IDE shows me for this method has "cliOptions as T" as the last line in the method. I think that the problem is T is erased when the method is compiled and so the "as T" does (effectively) nothing. I think the correct code would be "cliOptions.asType(optionsClass)".

Environment information:
/* -------------- groovy --version ------------------------------------ */
Groovy Version: 2.5.2 JVM: 1.8.0_172 Vendor: Oracle Corporation OS: Windows 7

/* --------------- IDE version info ------------------------------------- */
IntelliJ IDEA 2018.2.3 (Ultimate Edition)
Build #IU-182.4323.46, built on September 3, 2018
JRE: 1.8.0_152-release-1248-b8 amd64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Windows 7 6.1

The following code demonstrates the issue:
/* ------------------------ Begin Example Code ------------------------ */
import groovy.cli.Option
import groovy.cli.picocli.CliBuilder

class CliBuilderBug {
    interface CliArguments {
        @Option(longName='dummy') int dummy()
    }

    static void main(String[] args) {
        CliBuilder builder = new CliBuilder()

        def ok = builder.parseFromSpec(CliArguments, args) as CliArguments
        assert ok instanceof CliArguments // ok
        println "Using 'as' works."

        def notOk = builder.parseFromSpec(CliArguments, args)
        assert notOk instanceof LinkedHashMap // this assertion is true
        assert notOk instanceof CliArguments // fails
        println 'We never get here.'
    }
}
/* ------------------------ End Example Code ------------------------ */

I hope this is helpful, and thank you for your time.
- Kevin Perkins
NOTICE TO RECIPIENT:  If you are not the intended recipient of this e-mail, you are prohibited from sharing, copying, or otherwise using or disclosing its contents.  If you have received this e-mail in error, please notify the sender immediately by reply e-mail and permanently delete this e-mail and any attachments without reading, forwarding or saving them.  Thank you.

Reply | Threaded
Open this post in threaded view
|

Re: [Bug] [2.5.2] groovy.cli.picocli.CliBuilder.parseFromSpec does not cast its result to the correct type

Remko Popma
I do remember experiencing a similar problem at some point while working on the unit tests. 

I don’t remember how it got resolved. Could it be an environmental issue?

Maybe other people on this list have also seen this issue and can shed some light? (I think it’s a general Groovy question, not something particular to CliBuilder.)

Remko

(Shameless plug) Every java main() method deserves http://picocli.info

On Sep 12, 2018, at 13:40, Remko Popma <[hidden email]> wrote:

Kevin, that’s strange, there are working unit tests that do exactly the same...
For example:


On Wed, Sep 12, 2018 at 12:52 Kevin Perkins <[hidden email]> wrote:
Hello,

I think I've found a bug with groovy.cli.picocli.CliBuilder as of Groovy 2.5.2. I didn't find this particular issue in JIRA. I figured I'd ask here. The parseFromSpec method of groovy.cli.picocli.CliBuilder seems to always return a LinkedHashMap instead of the expected type (the class given as the first argument). The source my IDE shows me for this method has "cliOptions as T" as the last line in the method. I think that the problem is T is erased when the method is compiled and so the "as T" does (effectively) nothing. I think the correct code would be "cliOptions.asType(optionsClass)".

Environment information:
/* -------------- groovy --version ------------------------------------ */
Groovy Version: 2.5.2 JVM: 1.8.0_172 Vendor: Oracle Corporation OS: Windows 7

/* --------------- IDE version info ------------------------------------- */
IntelliJ IDEA 2018.2.3 (Ultimate Edition)
Build #IU-182.4323.46, built on September 3, 2018
JRE: 1.8.0_152-release-1248-b8 amd64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Windows 7 6.1

The following code demonstrates the issue:
/* ------------------------ Begin Example Code ------------------------ */
import groovy.cli.Option
import groovy.cli.picocli.CliBuilder

class CliBuilderBug {
    interface CliArguments {
        @Option(longName='dummy') int dummy()
    }

    static void main(String[] args) {
        CliBuilder builder = new CliBuilder()

        def ok = builder.parseFromSpec(CliArguments, args) as CliArguments
        assert ok instanceof CliArguments // ok
        println "Using 'as' works."

        def notOk = builder.parseFromSpec(CliArguments, args)
        assert notOk instanceof LinkedHashMap // this assertion is true
        assert notOk instanceof CliArguments // fails
        println 'We never get here.'
    }
}
/* ------------------------ End Example Code ------------------------ */

I hope this is helpful, and thank you for your time.
- Kevin Perkins
NOTICE TO RECIPIENT:  If you are not the intended recipient of this e-mail, you are prohibited from sharing, copying, or otherwise using or disclosing its contents.  If you have received this e-mail in error, please notify the sender immediately by reply e-mail and permanently delete this e-mail and any attachments without reading, forwarding or saving them.  Thank you.