Si j'ignore mon exigence prospective pour String je pourrais écrire:

        String.valueOf(
            true ? 'a' :
            Code.<Object>fail()
        )

Pour gérer à la fois char et String je peux utiliser le bizarre :

    Object symbol = 
            true ? 'a' :
            fail();
    System.out.println(String.valueOf(symbol)); 

Ou utilisez la sérialisation Java pour quelque chose d'utile:

        String.valueOf((java.io.Serializable)(
            true ? 'a' :
            fail()
        ))

Cela devrait probablement être considéré comme un bogue , mais je ne peux pas être dérangé par la lutte contre bugs.java.com.

Une solution alternative consiste à introduire un local inutile:

        String.valueOf((Comparable<?>)(
            true ? 'a' :
            fail()
        ))

Cela ne devrait pas être nécessaire, mais il est possible de rendre explicite le paramètre type à fail() et d'éviter tout casts explicites désagréables:

        String.valueOf((Character)(
            true ? 'a' :
            fail()
        ))

Belle syntaxe! Sinon, fail() pourrait avoir un cast redondant ...

Le problème est que les deux branches de l'opérateur ternaire renvoient des types différents.

Que dis-tu de ça:

    System.out.println(
        String.valueOf(
            true ? (Object)'a' : fail()
        )
    );

Boxer explicitement le personnage est une possibilité:

class Code {
    public static void main(String[] args) throws Throwable {
        System.out.println(
                String.valueOf(
                        true ? Character.valueOf('a') : fail()
                )
        );
    }
    private static <R> R fail() {
        throw null;
    }
}

L'erreur concernant une «invocation de méthode ambiguë» est correcte depuis Java 8.

Même avant Java 8, vous pouviez écrire

System.out.println(
    String.valueOf(
        true ? 'a' :
        true ? 'b' :
        true ? 'c' :
        Optional.empty().orElseThrow(Code::fail)
    )
);

sans erreurs du compilateur. Lorsque vous passez une condition conditionnelle similaire condition? 'a': genericMethod() à une méthode comme String.valueOf(…) , le compilateur a déduit <Object> pour fail() et a choisi String.valueOf(Object) raison de son inférence de type limitée.

Mais Java 8 a introduit Poly Expressions :

Le type d'une expression autonome peut être déterminé entièrement à partir du contenu de l'expression; en revanche, le type d'une expression poly peut être influencé par le type cible de l'expression ( §5 (Conversions et contextes) ).

Les deux, une invocation d'une méthode générique et un conditionnel contenant une expression poly (c'est-à-dire l'appel d'une méthode générique), sont des expressions poly.

Donc, essayer d'appeler String.valueOf(char) est valide avec ce conditionnel, comme nous pouvons en déduire <Character> pour fail() . Notez qu'aucune méthode n'est applicable dans un contexte d'appel strict , car les deux variantes nécessitent une opération de boxing ou de déballage. Dans un contexte d'appel lâche , les deux, String.valueOf(Object) et String.valueOf(char) sont applicables, car peu importe si nous déballons le Character après avoir invoqué fail() ou encadrons le char du littéral 'a' .

Puisque char n'est pas un sous-type d' Object et que Object n'est pas un sous-type de char , ni la méthode, String.valueOf(Object) ni String.valueOf(char) , n'est plus spécifique , par conséquent, une erreur de compilation est générée.

Il est plus difficile de juger de l'avertissement, car il n'y a pas de norme formelle pour les avertissements. À mon avis, chaque avertissement du compilateur qui prétend qu'un artefact de code source était obsolète malgré le code ne fera pas la même chose après sa suppression (ou sa suppression introduira même des erreurs), est incorrect. Il est intéressant de noter que l'avertissement existe déjà dans la version Java 7 de javac , où la suppression de la distribution ne fait vraiment aucune différence, alors peut-être que ce sont des restes qui doivent être mis à jour.

Les solutions de contournement du problème dépendent du contexte et il n'y a pas suffisamment d'informations à ce sujet. Notez qu'il n'y a qu'une seule branche nécessaire qui ne soit pas assignable à char , pour rendre la méthode String.valueOf(char) inapplicable. Cela se produira, dès que vous insérez la branche qui évalue à String . Vous pouvez également utiliser SurroundingClass.<Object>fail() pour obtenir le même type que les compilateurs pré-Java 8 déduits.

Ou supprimez entièrement la signature générique, car elle n'est pas nécessaire ici. La méthode générique fail() semble être une solution de contournement pour avoir une méthode de lancement dans un contexte d'expression. Une solution plus propre serait une méthode d'usine pour l'expression, par exemple

class Code {
    public static void main(String[] args) throws SpecificExceptionType {
        System.out.println(
            String.valueOf(switch(0) {
                case 0 -> 'a';
                case 1 -> 'b';
                case 2 -> 'c';
                default -> throw fail();
            })
        );
    }
    private static SpecificExceptionType fail() {
        return new SpecificExceptionType();
    }
    static class SpecificExceptionType extends Exception {
    }
}

Si les expressions de commutation ne sont pas possibles, vous pouvez utiliser

char c = fail();
Object o = fail();

Les deux ont l'avantage d'être précis sur le type réel d'exceptions potentiellement levées et n'ont pas besoin de recourir à des exceptions non contrôlées ou de throws Throwable déclarations throws Throwable . Le second peut sembler hacky, mais pas plus que la définition d'une méthode générique qui ne renvoie jamais rien.

Bien sûr, il existe d'autres possibilités pour le résoudre, si vous acceptez simplement l'introduction de plus de code, comme une méthode d'assistance dédiée pour la conversion de chaînes sans surcharge ou une méthode wrapper non générique pour la méthode de lancement. Ou une variable temporaire ou un type casts ou des types explicites pour les invocations génériques, etc. De plus, lorsque vous utilisez "" + (expression) ou (expression).toString() au lieu de String.valueOf(expression) , l'expression n'est pas un poly expression, par conséquent, ne pas provoquer une erreur "appel de méthode ambiguë".

Bien sûr, puisqu'il s'agit d'un faux avertissement, vous pouvez également conserver le cast et ajouter un @SuppressWarnings("cast") à la méthode (et attendre que cela soit corrigé par les développeurs du compilateur).

Réponse simple à une question simple:

class Code {
    
    public static void main(String[] args) throws Throwable {
        System.out.println(valueOf(
                true ? 'a' :
                true ? 'b' :
                true ? 'c' :
                fail()
            )
        );
    }
    private static <R> R fail() {
        throw null;
    }
    
    static String valueOf(Object object) {
        return String.valueOf(object);
    }
}

Ce code fonctionne tant que vous n'avez aucune valeur null . Pour couvrir également null valeurs null , vous devez introduire une méthode supplémentaire:

class Code {
    
    public static void main(String[] args) throws Throwable {
        System.out.println((
                true ? 'a' :
                true ? 'b' :
                true ? 'c' :
                fail()).toString()
        );
    }
    private static <R> R fail() {
        throw null;
    }
    
}

Les deux solutions ne nécessitent pas de modifier les nombreuses lignes de ? :

Ni l'avertissement du compilateur ni l'erreur ne sont un bogue. Dans le cas d'erreur, vous donnez au compilateur trop moins d'informations pour la sélection de la bonne méthode, dans la deuxième tentative, vous dites au compilateur de convertir un objet en un objet qui est inutile et qui vaut la peine de produire au moins un avertissement ;-)

Extrayez le résultat de l'expression dans une variable locale:

T obj =
        true ? 'a' :
                true ? 'b' :
                        true ? 'c' : fail();
System.out.println(String.valueOf(obj));

Apparemment, une bonne réponse est toujours là, mais une réponse intelligente est rare. Je pensais pouvoir dire: -

L'erreur que vous voyez est que, à un moment donné, char peut être retourné et à un moment donné, une instance de java.lang.Object peut être renvoyée. Ce qui correspond à plusieurs surcharges de String.valueOf pour provoquer l'ambiguïté.

Mais en regardant les choses de près, cela me semble être un bug. Imaginez ce qui suit: -

class Code {
    public static void main(String[] args) throws Throwable {
        System.out.println(
            String.valueOf(
                true ? (Object)'a' :
                true ? 'b' :
                true ? 'c' :
                fail())
        );
    }
    private static <R> R fail() {
        throw null;
    }
}

comme certaines surcharges de valueOf .
Essayez les brouillons suivants: -

class Code {
    public static void main(String[] args) throws Throwable {
        System.out.println(
            String.valueOf((Object)(
                true ? 'a' :
                true ? 'b' :
                true ? 'c' :
                fail())
            )
        );
    }
    private static <R> R fail() {
        throw null;
    }
}

La même erreur apparaît. Mais essayez le projet de code suivant: -

 valueOf((
                true?'a':
                true?'b':
                .
                .//a very enormous pieces of conditional branches using returning char.
                .//Note the second last element 'n', we use a cast.
                true?(Object)'n':
                fail())
            );

l'erreur disparaît.

Qu'est-il arrivé?

Comme l'une des réponses l'a suggéré, à un moment donné, le compilateur java était assez intelligent pour déduire un type uniforme pour un groupe d'instances, mais l'a perdu en cours de route.

Pourquoi appeler ça un bug

Si vous créez un arbre à partir de vos branches conditionnelles. comme:-

Ensuite, vous remarquez qu'un seul cast vers l'une des branches de gauche valide tout (aucune erreur). Le concept du compilateur semble être la dernière branche à droite qui ne soit pas analysée pour la résolution de type! (Essayez-le, c'est très étrange.) En supposant que fail() trouve dans l'une des branches de gauche, cela n'aura pas d'importance si le reposer un char ou une sorte d'objet auquel sera reduced à une résolution de java.lag.Object . La résolution de l'uniformité de type à partir de la condition afin de choisir la surcharge correcte d'une méthode est finalement vaincue. . Un bug surprenant en effet. Essayer les solutions de contournement suivantes devrait au moins éviter l'erreur dans un

  valueOf((
                true?'a':
                true?'b':
                .
                .//a very enormous pieces of conditional branches using returning char.
                .//Note the second last element 'n', we didn't cast.
                true?'n':
                fail())
            );

et celui-ci mais sans s'y limiter (vous pourriez en écrire un meilleur une fois que vous saurez comment contourner l'erreur.)

    private static char[] valueOf(String object) {return null; }
    private static char[] valueOf(char object) {return null; }
    private static char[] valueOf(Character object) {return null;}
    private static char[] valueOf(Object object) {return null;}
    private static <R> R fail() {throw null; }

Je suggérerais le premier s'il y a un besoin de lisibilité du code (au moins pour les autres développeurs).
true ici reste un «espace réservé» pour les morceaux spéculés de branches conditionnelles. Le cast box - (j'aime utiliser wrap ) chaque natif d'une instance de java.lang.Object Juste pour se conformer à ce que fail() pourrait retourner.
Remarque: un langage parfait est rare. N'ayez pas peur du bogue, s'il vous plaît.

Vous pouvez conclure l'appel avec un fournisseur pour obtenir un moyen avec:

class Code {
   public static void main(String[] args) throws Throwable {
        System.out.println(((Supplier<Object>) () ->
                true ? 'a' :
                        false ? 'b' :
                                false ? 'c' :
                                        fail()).get());
    }
    private static <R> R fail() { throw null; }
 }

'a' n'est pas une notation String ; remplacez-le par "a" (et je ne comprends pas non plus le cas d'utilisation - ou peut-être l'écrirais-je complètement différent en utilisant le moteur regex). Cependant, pour éviter les lancers inutiles ... vérifiez simplement avec instanceof ce que vous essayez même de lancer. De même, il y a peu de place pour les appels ambigus et les allers-retours inutiles.

vous n'avez pas besoin d'ajouter un cast (Object). Tout est un objet en java, pourquoi convertissez-vous de la valeur en (objet).

Object obj = (true ? 'a' : fail());
String str = String.valueOf(obj);