Objects contiene 2 overload di metodi in cui uno prende un oggetto e l'altro prende un Supplier di quell'oggetto:
public static <T> T requireNonNull(T obj, String message)
public static <T> T requireNonNull(T obj, Supplier<String> messageSupplier)
e simili
public static <T> T requireNonNullElse(T obj, T defaultObj)
public static <T> T requireNonNullElseGet(T obj, Supplier<? extends T> supplier)
I metodi che prendono un fornitore hanno il vantaggio di posticipare la valutazione del secondo argomento, ma lo svantaggio di creare un'istanza Supplier . Ciò è indicato nei documenti per requireNonNull(T obj, Supplier<String> messageSupplier) :
Unlike the method
requireNonNull(Object, String), this method allows creation of the message to be deferred until after the null check is made. While this may confer a performance advantage in the non-null case, when deciding to call this method care should be taken that the costs of creating the message supplier are less than the cost of just creating the string message directly.
Mentre la vera risposta sarebbe sempre quella di eseguire benchmark, è controproducente farlo per ogni caso e il più delle volte questo non è il collo di bottiglia. Tuttavia, ci imbattiamo in queste situazioni abbastanza spesso e dato che ci viene data la scelta, preferiamo fare quella giusta, nel qual caso "eyeballing" può essere molto utile.
Ad eccezione dei casi in cui il secondo argomento è già valutato (per il quale questa domanda ha poco senso), quando la creazione del secondo argomento sarebbe più costosa di un fornitore? Ci devono essere alcune linee guida su quando la scelta corretta è abbastanza ovvia.
Ricordo che String s è un caso speciale a causa del loro pool.