Nit: I know we aligned on this, but I think we can do a bit better with a method to go through some common scalar types as well as primitives from strings. Anything we don't cover can just be null. So the call for stringValue can call this if it's not a string type to make a more best effort?

Something like....

private fun parseStringToType(value: String, type: JavaTypeName): CodeBlock? {
    return when (type) {
        // primitives -> String
        ClassName.get(Int::class.java) -> CodeBlock.of("\$T.valueOf(\$S)", Integer::class.java, value)
        ClassName.get(Long::class.java) -> CodeBlock.of("\$T.valueOf(\$S)", java.lang.Long::class.java, value)
        ClassName.get(Float::class.java) -> CodeBlock.of("\$T.valueOf(\$S)", java.lang.Float::class.java, value)
        ClassName.get(Double::class.java) -> CodeBlock.of("\$T.valueOf(\$S)", java.lang.Double::class.java, value)
        ClassName.get(Boolean::class.java) -> CodeBlock.of("\$T.valueOf(\$S)", java.lang.Boolean::class.java, value)
        // Example for custom scalar
        ClassName.get(Uri::class.java) -> CodeBlock.of("\$T.parse(\$S)", Uri::class.java, value)
        // Add more custom scalar handlers here
        else -> null // fallback or throw error
    }
}

I like that idea and it would definitely make generated types easier to work with. I think supporting primitives would be simple enough but I'm curious about which other Java types you think should be automatically handled (java.net.Uri, java.math.BigDecimal, etc. would probably be commonly mapped to). I also wonder if this might make it inconsistent if only some default types are being generated.

Ultimately, the list of possible types that would find their way here would be only GraphQL scalar types (Int, Float, String, Boolean) and custom scalar types right? So while we could have BigDecimal registered as a custom schema type, it would have to be plugged in?

Perhaps we should just start with default scalar types and log an enhancement to consider a way to support default code blocks for custom types? I think there could be other ways to plug in initializing custom types so we may find that trying to deduce it while generating the code may not be the final solution anyway.

I think I'm thinking about it the other way around because the Java types are generated from the typeMapping the user provides. Looking at DataTypeGenerator I did see there's this block that checks for a few common Java types which does what Isaiah mentioned, so adding URI here would extend that flexibility.

private fun generateCode(
    value: Value<out Value<*>>,
    type: JavaTypeName,
    inputTypeDefinitions: List<InputObjectTypeDefinition>,
): CodeBlock? =
    when (type) {
        BIG_DECIMAL -> bigDecimalCodeBlock(value, type)
        CURRENCY -> currencyCodeBlock(value, type)
        LOCALE -> localeCodeBlock(value, type)
        ClassName.LONG.box() -> longCodeBlock(value, type)
        else -> defaultCodeBlock(value, type, inputTypeDefinitions)
    }

Ok, we might be talking about more than one thing then. I think I'd just be in favor of applying the fix you have here and then logging a ticket to investigate refactoring the mappings to be more robust and support more cases, including Uri (for example).

Sounds good! Agree that I would want to look more into how to support URI (using URI.create() vs. new URI() where one wraps the exception of malformed URIs and the other doesn't), thanks both for your input!

I'm a bit late to the party since this was already merged, but what do folks think about handling URI as a special case? On the one hand we should not, because why handle this one type specially, but on the other hand, it's a very common case.

Something like this works:

is StringValue -> {
                // Only generate string literal default values for string types to prevent invalid Java initialization
                if (type is ClassName && type == ClassName.get(String::class.java)) {
                    CodeBlock.of("\$S", value.value)
                } else if(type == ClassName.get(URI::class.java)) {
                    CodeBlock.of("URI.create(\$S)", value.value)
                } else {
                    null
                }
            }

I think this makes sense, I can add it in a follow-up PR.