Is there a reason @Produced is not allowed for Target=TYPE_USE?

[vlsi]

Use case:

public class GeneratorDescriptors {
    public static final HashMap<
        @Produced({
        @From(value = KnownManifestKeyGenerator.class, frequency = 50),
        @From(value = RegexStringGenerator.class, frequency = 50)
        })
            String,
        String> manifestAttributes = null;
}

Unfortunately, @Produced is not allowed for TYPE_USE, so I can't add the annotation like that.

[pholser]

@vlsi Thanks for this. I guess I hadn't imagined that programmers would use @Produced explicitly; rather, they'd use only the many instances of the repeatable @From:

public class GeneratorDescriptors {
    public static final HashMap<
        @From(value = KnownManifestKeyGenerator.class, frequency = 50),
        @From(value = RegexStringGenerator.class, frequency = 50)
            String,
        String> manifestAttributes = null;
}

If you believe it's important enough to allow @Produced on type uses, I can do it; there's no technical rationale preventing it. Let me know what you think.

Thanks also for diving deeply into junit-quickcheck! I'm always excited to hear of opportunities for improvement.

[pholser]

@visi In fact, if you're interested, I could use some extra eyes on #173. Meta-annotation support would allow you to craft a meta-annotation marked with the @Froms above, so that the type decl might read:

    public static final HashMap<@ManifestKeyHalfAndHalf String, String> manifestAttributes = null;
}

[vlsi]

@pholser ,

I've tried a bit more. Meta-annotation helps, however configure(Regex) method is not called for some reason

public class GeneratorDescriptors {
    @From(value = KnownManifestKeyGenerator.class, frequency = 10)
    @Regex("[-_a-zA-Z0-9]")
    @From(value = RegexStringGenerator.class, frequency = 90)
    @Retention(RetentionPolicy.RUNTIME)
    @Target(ElementType.TYPE_USE)
    @GeneratorConfiguration
    @interface ManifestKey {
    }

    public static final HashMap<@ManifestKey String, String> manifestAttributes = null;
}

@Target([PARAMETER, FIELD, ANNOTATION_TYPE, TYPE_USE])
@Retention(RetentionPolicy.RUNTIME)
@GeneratorConfiguration
public @interface Regex {
    String value()
}

class RegexStringGenerator extends AbstractStringGenerator {
    private Generex generex
    private InRange range
    private Size size

    public void configure(Regex regex) {
        this.generex = new Generex(regex.value())
    }

    public void configure(InRange range) {
        this.range = range
    }

    public void configure(Size size) {
        this.size = size
    }

    @Override
    String generate(SourceOfRandomness random, GenerationStatus status) {
        if (generex == null) {
            throw new IllegalArgumentException("@Regex was not specified for RegexStringGenerator")
        }
        generex.setSeed(random.nextLong())
        return generex.random()
    }

    @Override
    protected int nextCodePoint(SourceOfRandomness random) {
        return 0
    }

    @Override
    protected boolean codePointInRange(int codePoint) {
        return true
    }
}

[vlsi]

On top of that, I wonder how could I configure multiple RegexStringGenerator generators each with its own Regex.
It looks like all the annotations are "flat", so @Regex annotation cannot be tied to a particular @From

[vlsi]

I hadn't imagined that programmers would use @Produced explicitly; rather,

@pholser the error is the same for multi-from as well:

    public static final HashMap<
        @From(value = StringGenerator.class)
        @From(value = StringGenerator.class) String,
        String> manifestAttributes2 = null;

.../GeneratorDescriptors.java
Error:(45, 9) java: container com.pholser.junit.quickcheck.Produced is not applicable in this type context

[pholser]

@visi Ah ok, thanks. I'll investigate. Sounds like we'd need to make the change regardless.

[vlsi]

Yes. TYPE_USE for @Producer would simplify quickcheck use

[pholser]

@vlsi This is on 0.9 branch right now. I'll merge to master once you're satisfied this behaves as desired.

[vlsi]

@pholser , id is not clear what is the suggested way to test 0.9 branch.
Is that intentional that you do not use -SNAPSHOT in the version?

I don't like to "install random dependencies" to the local maven repository.

[vlsi]

The change seems to be trivial, and it should work.
It might make sense to have the relevant tests at the junit-quickcheck though.

[pholser]

Absolutely. I've added test class GeneratorDescriptorsIssue235, which would fail compilation prior to the change.

[pholser]

I will cut a 0.9.1 soon with this change in it.