[code-reflection] RFR: Unary plus

[Maurizio Cimadamore]

On Wed, 14 Aug 2024 14:25:54 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

> in test4, we are unboxing then boxing without a reason

That is odd, yes. But note that javac bytecode generates same odd stuff:


Code:
      stack=1, locals=1, args_size=1
         0: aload_0
         1: invokevirtual #2                  // Method java/lang/Integer.intValue:()I
         4: invokestatic  #3                  // Method java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
         7: areturn


The "issue" is that the operand type (`tree.arg.type`) is `Integer`, but `tree.type` is `int` - because the unary operator is seen as as an operator from `int` to `int` (so you need to unbox to apply the `+`).

This is backed up by the JLS:

> The type of the operand expression of the unary + operator must be a type that is convertible ([§5.1.8](https://docs.oracle.com/javase/specs/jls/se22/html/jls-5.html#jls-5.1.8)) to a primitive numeric type, or a compile-time error occurs.

And

> Unary numeric promotion ([§5.6](https://docs.oracle.com/javase/specs/jls/se22/html/jls-5.html#jls-5.6)) is performed on the operand. The type of the unary plus expression is the promoted type of the operand.

So, these conversions are actually mandated because: the operand is a reference, so "promoting" means doing "unboxing". Then, the "promoted type" is just `int` (the primitive type), and that is the type of the `+v` expression. But then you need to rebox to respect the return type. So this is all good (albeit admittedly odd).

-------------

PR Comment: https://git.openjdk.org/babylon/pull/213#issuecomment-2289033524