Improving readability of type/casting error messages

Jonathan Gibbons jonathan.gibbons at
Fri Dec 5 02:32:22 UTC 2014


I am sorry you feel the error messages have gotten less readable over 
time, because we have put a significant amount of effort into improving 
the messages.

It is certainly the case that the type system has gotten a lot more 
complex over the past few releases, and in some of the more complex 
cases, it is indeed hard to create readable messages .  In particular, 
although you can interpret a series of phrases to mean

"this::addProperty returns void but thenApply() expects it to return a type
that extends Object"

that sort of transformation is almost impossible within javac, 
especially given that we need to be able to localize the message for the 
supported non-English locales.

The current design goal for the messages is to have the message begin 
with a short 1-line summary, followed by the code in question, to give 
some context, followed by any additional details the compiler is able to 

That being said, there may well be specific instances where messages can 
be improved, and we welcome input when you find specific messages that 
are unclear.

-- Jon

On 12/04/2014 06:05 PM, cowwoc wrote:
> Hi,
> With the addition of lambdas in Java8, I'm running into generics error
> messages more frequently than ever before and the messages have gotten less
> and less readable over time.
> I'll start by discussing a seemingly benign error message:
> incompatible types: bad return type in lambda expression
>      Promise<Optional<GetPostalCode>> cannot be converted to Optional
> for this code:
> 		Promise<Optional<GetPostalCode>> result = ->
> 		{
> 			// do something
> 			return Optional.empty();
> 		}).orElseGet(() ->
> 		{
> 			return getPostalCode();
> 		});
> 		return result;
> The line triggering the error is: "return getPostalCode()"
> Here's my problem:
> 1. getPostalCode() returns "Promise<Optional<GetPostalCode>>"
> 2. "result" is of the same type.
> 3. Looking at this code, it's not obvious why the compiler is trying to cast
> the output to "Optional"
> I've run across this kind of problem very often. The problem I am referring
> to is not the specific error message but rather the fact that you're forcing
> developers to reverse engineer the compiler in their head to figure out what
> is going wrong.
> Instead of forcing developers to do figure out why the compiler is
> attempting a seemingly wrong cast, couldn't the error message explain it
> explicitly? I don't mind passing extra command-line parameters into the
> compiler to get more verbose explanations, so long as this is possible.
> The second kind of error I am running into is:
> method thenApply in class Promise<T> cannot be applied to given types;
>    required: Function<? super PostProperty,? extends U>
>    found: this::addProperty
>    reason: cannot infer type-variable(s) U
>      (argument mismatch; bad return type in method reference
>        void cannot be converted to U)
>    where U,T are type-variables:
>      U extends Object declared in method <U>thenApply(Function<? super T,?
> extends U>)
>      T extends Object declared in class Promise
> I don't know about you, but (as a human being) I find this message very hard
> to read. It sounds as if the message was written for computers to parse, not
> people. What the compiler is actually trying to say is that
> "this::addProperty returns void but thenApply() expects it to return a type
> that extends Object".
> Is it possible for someone to investigate improving these messages?
> Thank you,
> Gili
> --
> View this message in context:
> Sent from the OpenJDK Compiler Development mailing list archive at

More information about the compiler-dev mailing list