Effectively final vs final - Different behavior

First of all, we are talking about local variables only. Effectively final does not apply to fields. This is important, since the semantics for final fields are very distinct and are subject to heavy compiler optimizations and memory model promises, see $17.5.1 on the semantics of final fields.

On a surface level final and effectively final for local variables are indeed identical. However, the JLS makes a clear distinction between the two which actually has a wide range of effects in special situations like this.

Premise

From JLS§4.12.4 about final variables:

A constant variable is a final variable of primitive type or type String that is initialized with a constant expression (§15.29). Whether a variable is a constant variable or not may have implications with respect to class initialization (§12.4.1), binary compatibility (§13.1), reachability (§14.22), and definite assignment (§16.1.1).

Since int is primitive, the variable a is such a constant variable.

Further, from the same chapter about effectively final:

Certain variables that are not declared final are instead considered effectively final: ...

So from the way this is worded, it is clear that in the other example, a is not considered a constant variable, as it is not final, but only effectively final.

Behavior

Now that we have the distinction, lets lookup what is going on and why the output is different.

You are using the conditional operator ? : here, so we have to check its definition. From JLS§15.25:

There are three kinds of conditional expressions, classified according to the second and third operand expressions: boolean conditional expressions, numeric conditional expressions, and reference conditional expressions.

In this case, we are talking about a numeric conditional expressions, from JLS§15.25.2:

The type of a numeric conditional expression is determined as follows:

And that is the part where the two cases get classified differently.

effectively final

The version that is effectively final is matched by this rule:

Otherwise, general numeric promotion (§5.6) is applied to the second and third operands, and the type of the conditional expression is the promoted type of the second and third operands.

Which is the same behavior as if you would do 5 + 'd', i.e. int + char, which results in int. See JLS§5.6

Numeric promotion determines the promoted type of all the expressions in a numeric context. The promoted type is chosen such that each expression can be converted to the promoted type, and, in the case of an arithmetic operation, the operation is defined for values of the promoted type. The order of expressions in a numeric context is not significant for numeric promotion. The rules are as follows:

[...]

Next, widening primitive conversion (§5.1.2) and narrowing primitive conversion (§5.1.3) are applied to some expressions, according to the following rules:

In a numeric choice context, the following rules apply:

If any expression is of type int and is not a constant expression (§15.29), then the promoted type is int, and other expressions that are not of type int undergo widening primitive conversion to int.

So everything is promoted to int as a is an int already. That explains the output of 97.

final

The version with the final variable is matched by this rule:

If one of the operands is of type T where T is byte, short, or char, and the other operand is a constant expression (§15.29) of type int whose value is representable in type T, then the type of the conditional expression is T.

The final variable a is of type int and a constant expression (because it is final). It is representable as char, hence the outcome is of type char. That concludes the output a.

String example

The example with the string equality is based on the same core difference, final variables are treated as constant expression/variable, and effectively final is not.

In Java, string interning is based on constant expressions, hence

"a" + "b" + "c" == "abc"

is true as well (dont use this construct in real code).

See JLS§3.10.5:

Moreover, a string literal always refers to the same instance of class String. This is because string literals - or, more generally, strings that are the values of constant expressions (§15.29) - are "interned" so as to share unique instances, using the method String.intern (§12.5).

Easy to overlook as it is primarily talking about literals, but it actually applies to constant expressions as well.

Another aspect is that if the variable is declared final in the body of the method it has a different behaviour from a final variable passed as parameter.

public void testFinalParameters(final String a, final String b) {
  System.out.println(a + b == "ab");
}

...
testFinalParameters("a", "b"); // Prints false

while

public void testFinalVariable() {
   final String a = "a";
   final String b = "b";
   System.out.println(a + b == "ab");  // Prints true
}

...
testFinalVariable();

it happens because the compiler knows that using final String a = "a" the a variable will always have the "a" value so that a and "a" can be interchanged without problems. Differently, if a is not defined final or it is defined final but its value is assigned at runtime (as in the example above where final is the a parameter) the compiler doesn't know anything before its use. So the concatenation happens at runtime and a new string is generated, not using the intern pool.

Basically the behaviour is: if the compiler knows that a variable is a constant can use it the same as using the constant.

If the variable is not defined final (or it is final but its value is defined at runtime) there is no reason for the compiler to handle it as a constant also if its value is equal to a constant and its value is never changed.