Chapter 15. Expressions

The left-hand operand of a binary operator appears to be fully evaluated before any part of the right-hand operand is evaluated.

If the operator is a compound-assignment operator (15.26.2), then evaluation of the left-hand operand includes both remembering the variable that the left-hand operand denotes and fetching and saving that variable's value for use in the implied binary operation.

If evaluation of the left-hand operand of a binary operator completes abruptly, no part of the right-hand operand appears to have been evaluated.

class Test1 {
  public static void main(String[] args) {
    int i = 2;
    int j = (i=3) * i;
    System.out.println(j);
  }
}

9

class Test2 {
  public static void main(String[] args) {
    int a = 9;
    a += (a = 3);  // first example
    System.out.println(a);
    int b = 9;
    b = b + (b = 3);  // second example
    System.out.println(b);
  }
}

12
12

class Test3 {
  public static void main(String[] args) {
    int j = 1;
    try {
      int i = forgetIt() / (j = 2);
    } catch (Exception e) {
      System.out.println(e);
      System.out.println("Now j = " + j);
    }
  }
  static int forgetIt() throws Exception {
    throw new Exception("I'm outta here!");
  }
}

java.lang.Exception: I'm outta here!
Now j = 1

The Java programming language guarantees that every operand of an operator (except the conditional operators &&, ||, and ? :) appears to be fully evaluated before any part of the operation itself is performed.

If the binary operator is an integer division / (15.17.2) or integer remainder % (15.17.3), then its execution may raise an ArithmeticException, but this exception is thrown only after both operands of the binary operator have been evaluated and only if these evaluations completed normally.

class Test {
  public static void main(String[] args) {
    int divisor = 0;
    try {
      int i = 1 / (divisor * loseBig());
    } catch (Exception e) {
      System.out.println(e);
    }
  }
  static int loseBig() throws Exception {
    throw new Exception("Shuffle off to Buffalo!");
  }
}

java.lang.Exception: Shuffle off to Buffalo!

java.lang.ArithmeticException: / by zero

The Java programming language respects the order of evaluation indicated explicitly by parentheses and implicitly by operator precedence.

An implementation of the Java programming language may not take advantage of algebraic identities such as the associative law to rewrite expressions into a more convenient computational order unless it can be proven that the replacement expression is equivalent in value and in its observable side effects, even in the presence of multiple threads of execution (using the thread execution model in 17 (Threads and Locks)), for all possible computational values that might be involved.

In the case of floating-point calculations, this rule applies also for infinity and not-a-number (NaN) values.

For example, !(x<y) may not be rewritten as x>=y, because these expressions have different values if either x or y is NaN or both are NaN.

Specifically, floating-point calculations that appear to be mathematically associative are unlikely to be computationally associative. Such computations must not be naively reordered.

For example, it is not correct for a Java compiler to rewrite 4.0*x*0.5 as 2.0*x; while roundoff happens not to be an issue here, there are large values of x for which the first expression produces infinity (because of overflow) but the second expression produces a finite result.

class Test {
  public static void main(String[] args) {
    double d = 8E307;
    System.out.println(4.0 * d * 0.5);
    System.out.println(2.0 * d);
  }
}

Infinity
1.6E308

In contrast, integer addition and multiplication are provably associative in the Java programming language.

For example a+b+c, where a, b, and c are local variables (this simplifying assumption avoids issues involving multiple threads and volatile variables), will always produce the same answer whether evaluated as (a+b)+c or a+(b+c); if the expression b+c occurs nearby in the code, a smart Java compiler may be able to use this common subexpression.

In a method or constructor invocation or class instance creation expression, argument expressions may appear within the parentheses, separated by commas. Each argument expression appears to be fully evaluated before any part of any argument expression to its right.

If evaluation of an argument expression completes abruptly, no part of any argument expression to its right appears to have been evaluated.

class Test1 {
  public static void main(String[] args) {
    String s = "going, ";
    print3(s, s, s = "gone");
  }
  static void print3(String a, String b, String c) {
    System.out.println(a + b + c);
  }
}

going, going, gone

class Test2 {
  static int id;
  public static void main(String[] args) {
    try {
      test(id = 1, oops(), id = 3);
    } catch (Exception e) {
      System.out.println(e + ", id=" + id);
    }
  }
  static int test(int a, int b, int c) {
    return a + b + c;
  }
  static int oops() throws Exception {
    throw new Exception("oops");
  }
}

java.lang.Exception: oops, id=1

The order of evaluation for some expressions is not completely covered by these general rules, because these expressions may raise exceptional conditions at times that must be specified. See the detailed explanations of evaluation order for the following kinds of expressions:

A literal (3.10) denotes a fixed, unchanging value.

The following production from 3.10 is shown here for convenience:

The type of a literal is determined as follows:

Evaluation of a lexical literal always completes normally.

A class literal is an expression consisting of the name of a class, interface, array type, or primitive type, or the pseudo-type void, followed by a '.' and the token class.

The TypeName must denote a class or interface that is accessible (6.6). It is a compile-time error if the TypeName denotes a class or interface that is not accessible, or denotes a type variable.

The type of C.class, where C is the name of a class, interface, or array type (4.3), is Class<C>.

The type of p.class, where p is the name of a primitive type (4.2), is Class<B>, where B is the type of an expression of type p after boxing conversion (5.1.7).

The type of void.class (8.4.5) is Class<Void>.

A class literal evaluates to the Class object for the named class, interface, array type, or primitive type (or for void), as defined by the defining class loader (12.2) of the class of the current instance.

The keyword this may be used as an expression in the following contexts:

When used as an expression, the keyword this denotes a value that is a reference either to the object for which the instance method was invoked (15.12), or to the object being constructed. The value denoted by this in a lambda body (15.27.2) is the same as the value denoted by this in the surrounding context.

The keyword this is also used in explicit constructor invocation statements (8.8.7.1), and to denote the receiver parameter of a method or constructor (8.4).

It is a compile-time error if a this expression occurs in a static context (8.1.3).

Let C by the innermost enclosing class or interface declaration of a this expression. If C is generic, with type parameters F₁,...,F_n, the type of this is C<F₁,...,F_n>. Otherwise, the type of this is C.

At run time, the class of the actual object referred to may be C or a subclass of C (8.1.5.

class IntVector {
  int[] v;
  boolean equals(IntVector other) {
    if (this == other)
      return true;
    if (v.length != other.v.length)
      return false;
    for (int i = 0; i < v.length; i++) {
      if (v[i] != other.v[i]) return false;
    }
    return true;
  }
}

Any lexically enclosing instance (8.1.3) can be referred to by explicitly qualifying the keyword this.

Let n be an integer such that TypeName denotes the n'th lexically enclosing class or interface declaration of the class or interface whose declaration immediately encloses the qualified this expression.

The value of a qualified this expression TypeName.this is the n'th lexically enclosing instance of this.

If TypeName denotes a generic class, with type parameters F₁,...,F_n, the type of the qualified this expression is TypeName<F₁,...,F_n>. Otherwise, the type of the qualified this expression is TypeName.

It is a compile-time error if a qualified this expression occurs in a static context (8.1.3).

It is a compile-time error if the class or interface whose declaration immediately encloses a qualified this expression is not an inner class of TypeName or TypeName itself.

A parenthesized expression is a primary expression whose type is the type of the contained expression and whose value at run time is the value of the contained expression. If the contained expression denotes a variable then the parenthesized expression also denotes that variable.

The use of parentheses affects only the order of evaluation, except for a corner case whereby (-2147483648) and (-9223372036854775808L) are legal but -(2147483648) and -(9223372036854775808L) are illegal.

This is because the decimal literals 2147483648 and 9223372036854775808L are allowed only as an operand of the unary minus operator (3.10.1).

In particular, the presence or absence of parentheses around an expression does not affect whether a variable is definitely assigned, definitely assigned when true, definitely assigned when false, definitely unassigned, definitely unassigned when true, or definitely unassigned when false (16 (Definite Assignment)).

If a parenthesized expression appears in a context of a particular kind with target type T (5 (Conversions and Contexts)), its contained expression similarly appears in a context of the same kind with target type T.

If the contained expression is a poly expression (15.2), the parenthesized expression is also a poly expression. Otherwise, it is a standalone expression.

A poly parenthesized expression is compatible with a target type T if its contained expression is compatible with T.

If ClassOrInterfaceTypeToInstantiate ends with TypeArguments (rather than <>), then ClassOrInterfaceTypeToInstantiate must denote a well-formed parameterized type (4.5), or a compile-time error occurs.

If ClassOrInterfaceTypeToInstantiate ends with <>, but the class or interface denoted by the Identifier in ClassOrInterfaceTypeToInstantiate is not generic, then a compile-time error occurs.

If the class instance creation expression ends in a class body, then the class being instantiated is an anonymous class. Then:

If a class instance creation expression does not declare an anonymous class, then:

Let C be the class being instantiated, and let i be the instance being created. If C is an inner class, then i may have an immediately enclosing instance (8.1.3), determined as follows:

If C is an anonymous class, and its direct superclass S is an inner class, then i may have an immediately enclosing instance with respect to S, determined as follows:

Let C be the class being instantiated. To create an instance of C, i, a constructor of C is chosen at compile time by the following rules.

First, the actual arguments to the constructor invocation are determined:

Second, a constructor of C and corresponding throws clause and return type are determined:

It is a compile-time error if an argument to a class instance creation expression is not compatible with its target type, as derived from the invocation type (15.12.2.6).

If the compile-time declaration is applicable by variable arity invocation (15.12.2.4), then where the last formal parameter type of the invocation type of the constructor is F_n[], it is a compile-time error if the type which is the erasure of F_n is not accessible at the point of invocation.

The type of the class instance creation expression is the return type corresponding to the chosen constructor, as defined above.

At run time, evaluation of a class instance creation expression is as follows.

First, if the class instance creation expression is a qualified class instance creation expression, the qualifying primary expression is evaluated. If the qualifying expression evaluates to null, a NullPointerException is raised, and the class instance creation expression completes abruptly. If the qualifying expression completes abruptly, the class instance creation expression completes abruptly for the same reason.

Next, space is allocated for the new class instance. If there is insufficient space to allocate the object, evaluation of the class instance creation expression completes abruptly by throwing an OutOfMemoryError.

The new object contains new instances of all the fields declared in the specified class and all its superclasses. As each new field instance is created, it is initialized to its default value (4.12.5).

Next, the actual arguments to the constructor are evaluated, left-to-right. If any of the argument evaluations completes abruptly, any argument expressions to its right are not evaluated, and the class instance creation expression completes abruptly for the same reason.

Next, the selected constructor of the specified class is invoked. This results in invoking at least one constructor for each superclass of the class. This process can be directed by explicit constructor invocation statements (8.8.7.1) and is specified in detail in 12.5.

The value of a class instance creation expression is a reference to the newly created object of the specified class. Every time the expression is evaluated, a fresh object is created.

class List {
  int value;
  List next;
  static List head = new List(0);
  List(int n) { value = n; next = head; head = this; }
}
class Test {
  public static void main(String[] args) {
    int id = 0, oldid = 0;
    try {
      for (;;) {
        ++id;
        new List(oldid = id);
      }
    } catch (Error e) {
      List.head = null;
      System.out.println(e.getClass() + ", " + (oldid==id));
    }
  }
}

class java.lang.OutOfMemoryError, false

An anonymous class is implicitly declared by a class instance creation expression or by an enum constant that ends with a class body (8.9.1).

An anonymous class is never abstract (8.1.1.1).

An anonymous class is never sealed (8.1.1.2), and thus has no permitted direct subclasses (8.1.6).

An anonymous class declared by a class instance creation expression is never final (8.1.1.2).

An anonymous class declared by an enum constant is always final.

An anonymous class being non-final is relevant in casting, in particular the narrowing reference conversion allowed for the cast operator (5.5). On the other hand, it is not relevant to subclassing, because it is impossible to declare a subclass of an anonymous class (an anonymous class cannot be named by an extends clause) despite the anonymous class being non-final.

An anonymous class is always an inner class (8.1.3).

Like a local class or interface (14.3), an anonymous class is not a member of any package, class, or interface (7.1, 8.5).

The direct superclass type or direct superinterface type of an anonymous class declared by a class instance creation expression is given by the expression (15.9.1), with type arguments inferred as necessary while choosing a constructor (15.9.3). If a direct superinterface type is given, the direct superclass type is Object.

The direct superclass type of an anonymous class declared by an enum constant is the type of the declaring enum class.

The ClassBody of the class instance creation expression or enum constant declares fields (8.3), methods (8.4), member classes (8.5), member interfaces (9.1.1.3), instance initializers (8.6), and static initializers (8.7) of the anonymous class. The constructor of an anonymous class is always implicit (15.9.5.1).

If a class instance creation expression with a ClassBody uses a diamond (<>) for the type arguments of the class to be instantiated, then for all non-private methods declared in the ClassBody, it is as if the method declaration is annotated with @Override (9.6.4.4).

When <> is used, the inferred type arguments may not be as anticipated by the programmer. Consequently, the supertype of the anonymous class may not be as anticipated, and methods declared in the anonymous class may not override supertype methods as intended. Treating such methods as if annotated with @Override (if they are not explicitly annotated with @Override) helps avoid silently incorrect programs.

An array creation expression is used to create new arrays (10 (Arrays)).

The following production from 4.3 is shown here for convenience:

An array creation expression creates an object that is a new array whose elements are of the type specified by the PrimitiveType or ClassOrInterfaceType.

It is a compile-time error if the ClassOrInterfaceType does not denote a reifiable type (4.7). Otherwise, the ClassOrInterfaceType may name any named reference type, even an abstract class type (8.1.1.1) or an interface type.

The rules above imply that the element type in an array creation expression cannot be a parameterized type, unless all type arguments to the parameterized type are unbounded wildcards.

The type of each dimension expression within a DimExpr must be a type that is convertible (5.1.8) to an integral type, or a compile-time error occurs.

Each dimension expression undergoes unary numeric promotion (5.6). The promoted type must be int, or a compile-time error occurs.

The type of the array creation expression is an array type that can denoted by a copy of the array creation expression from which the new keyword and every DimExpr expression and array initializer have been deleted.

new double[3][3][]

double[][][]

At run time, evaluation of an array creation expression behaves as follows:

class Test1 {
  public static void main(String[] args) {
    int i = 4;
    int ia[][] = new int[i][i=3];
    System.out.println(
      "[" + ia.length + "," + ia[0].length + "]");
  }
}

[4,3]

class Test2 {
  public static void main(String[] args) {
    int[][] a = { { 00, 01 }, { 10, 11 } };
    int i = 99;
    try {
      a[val()][i = 1]++;
    } catch (Exception e) {
      System.out.println(e + ", i=" + i);
    }
  }
  static int val() throws Exception {
    throw new Exception("unimplemented");
  }
}

java.lang.Exception: unimplemented, i=99

float[][] matrix = new float[3][3];

float[][] matrix = new float[3][];
for (int d = 0; d < matrix.length; d++)
  matrix[d] = new float[3];

Age[][][][][] Aquarius = new Age[6][10][8][12][];

Age[][][][][] Aquarius = new Age[6][][][][];
for (int d1 = 0; d1 < Aquarius.length; d1++) {
  Aquarius[d1] = new Age[10][][][];
  for (int d2 = 0; d2 < Aquarius[d1].length; d2++) {
    Aquarius[d1][d2] = new Age[8][][];
    for (int d3 = 0; d3 < Aquarius[d1][d2].length; d3++) {
      Aquarius[d1][d2][d3] = new Age[12][];
    }
  }
}

Age[] Hair = { new Age("quartz"), new Age("topaz") };
Aquarius[1][9][6][9] = Hair;

float triang[][] = new float[100][];
for (int i = 0; i < triang.length; i++)
  triang[i] = new float[i+1];

If evaluation of an array creation expression finds there is insufficient memory to perform the creation operation, then an OutOfMemoryError is thrown. If the array creation expression does not have an array initializer, then this check occurs only after evaluation of all dimension expressions has completed normally. If the array creation expression does have an array initializer, then an OutOfMemoryError can occur when an object of reference type is allocated during evaluation of a variable initializer expression, or when space is allocated for an array to hold the values of a (possibly nested) array initializer.

class Test3 {
  public static void main(String[] args) {
    int len = 0, oldlen = 0;
    Object[] a = new Object[0];
    try {
      for (;;) {
        ++len;
        Object[] temp = new Object[oldlen = len];
        temp[0] = a;
        a = temp;
      }
    } catch (Error e) {
      System.out.println(e + ", " + (oldlen==len));
    }
  }
}

java.lang.OutOfMemoryError, true

An array access expression refers to a variable that is a component of an array.

An array access expression contains two subexpressions, the array reference expression (before the left bracket) and the index expression (within the brackets).

Note that the array reference expression may be a name or any primary expression that is not an array creation expression (15.10).

The type of the array reference expression must be an array type (call it T[], an array whose components are of type T), or a compile-time error occurs.

The index expression undergoes unary numeric promotion (5.6). The promoted type must be int, or a compile-time error occurs.

The type of the array access expression is the result of applying capture conversion (5.1.10) to T.

The result of an array access expression is a variable of type T, namely the variable within the array selected by the value of the index expression.

This resulting variable, which is a component of the array, is never considered final, even if the array reference expression denoted a final variable.

At run time, evaluation of an array access expression behaves as follows:

class Test1 {
  public static void main(String[] args) {
    int[] a = { 11, 12, 13, 14 };
    int[] b = { 0, 1, 2, 3 };
    System.out.println(a[(a=b)[3]]);
  }
}

14

class Test2 {
  public static void main(String[] args) {
    int index = 1;
    try {
      skedaddle()[index=2]++;
    } catch (Exception e) {
      System.out.println(e + ", index=" + index);
    }
  }
  static int[] skedaddle() throws Exception {
    throw new Exception("Ciao");
  }
}

java.lang.Exception: Ciao, index=1

class Test3 {
  public static void main(String[] args) {
    int index = 1;
    try {
      nada()[index=2]++;
    } catch (Exception e) {
      System.out.println(e + ", index=" + index);
    }
  }
  static int[] nada() { return null; }
}

java.lang.NullPointerException, index=2

class Test4 {
  public static void main(String[] args) {
    int[] a = null;
    try {
      int i = a[vamoose()];
      System.out.println(i);
    } catch (Exception e) {
      System.out.println(e);
    }
  }
  static int vamoose() throws Exception {
    throw new Exception("Twenty-three skidoo!");
  }
}

java.lang.Exception: Twenty-three skidoo!

The type of the Primary must be a reference type T, or a compile-time error occurs.

The meaning of the field access expression is determined as follows:

At run time, the result of the field access expression is computed as follows: (assuming that the program is correct with respect to definite assignment analysis, that is, every blank final variable is definitely assigned before access)

Note that only the type of the Primary expression, not the class of the actual object referred to at run time, is used in determining which field to use.

class S       { int x = 0; }
class T extends S { int x = 1; }
class Test1 {
  public static void main(String[] args) {
    T t = new T();
    System.out.println("t.x=" + t.x + when("t", t));
    S s = new S();
    System.out.println("s.x=" + s.x + when("s", s));
    s = t;
    System.out.println("s.x=" + s.x + when("s", s));
  }
  static String when(String name, Object t) {
    return " when " + name + " holds a "
            + t.getClass() + " at run time.";
  }
}

t.x=1 when t holds a class T at run time.
s.x=0 when s holds a class S at run time.
s.x=0 when s holds a class T at run time.

class S       { int x = 0; int z() { return x; } }
class T extends S { int x = 1; int z() { return x; } }
class Test2 {
  public static void main(String[] args) {
    T t = new T();
    System.out.println("t.z()=" + t.z() + when("t", t));
    S s = new S();
    System.out.println("s.z()=" + s.z() + when("s", s));
    s = t;
    System.out.println("s.z()=" + s.z() + when("s", s));
  }
  static String when(String name, Object t) {
    return " when " + name + " holds a "
            + t.getClass() + " at run time.";
  }
}

t.z()=1 when t holds a class T at run time.
s.z()=0 when s holds a class S at run time.
s.z()=1 when s holds a class T at run time.

class Test3 {
  static String mountain = "Chocorua";
  static Test3 favorite(){
    System.out.print("Mount ");
    return null;
  }
  public static void main(String[] args) {
    System.out.println(favorite().mountain);
  }
}

Mount Chocorua

The form super.Identifier refers to the field named Identifier of the current object, but with the current object viewed as an instance of the superclass of the current class.

The form T.super.Identifier refers to the field named Identifier of the lexically enclosing instance corresponding to T, but with that instance viewed as an instance of the superclass of T.

The forms using the keyword super may be used in the locations within a class declaration that allow the keyword this as an expression (15.8.3).

It is a compile-time error if a field access expression using the keyword super appears in a static context (8.1.3).

For a field access expression of the form super.Identifier:

For a field access expression of the form T.super.Identifier:

Suppose that a field access expression super.f appears within class C, and the immediate superclass of C is class S. If f in S is accessible from class C (6.6), then super.f is treated as if it had been the expression this.f in the body of class S. Otherwise, a compile-time error occurs.

Thus, super.f can access the field f that is accessible in class S, even if that field is hidden by a declaration of a field f in class C.

Suppose that a field access expression T.super.f appears within class C, and the immediate superclass of the class denoted by T is a class whose fully qualified name is S. If f in S is accessible from C, then T.super.f is treated as if it had been the expression this.f in the body of class S. Otherwise, a compile-time error occurs.

Thus, T.super.f can access the field f that is accessible in class S, even if that field is hidden by a declaration of a field f in class T.

interface I       { int x = 0; }
class T1 implements I { int x = 1; }
class T2 extends T1   { int x = 2; }
class T3 extends T2 {
  int x = 3;
  void test() {
    System.out.println("x=\t\t"      + x);
    System.out.println("super.x=\t\t"  + super.x);
    System.out.println("((T2)this).x=\t" + ((T2)this).x);
    System.out.println("((T1)this).x=\t" + ((T1)this).x);
    System.out.println("((I)this).x=\t"  + ((I)this).x);
  }
}
class Test {
  public static void main(String[] args) {
    new T3().test();
  }
}

x=        3
super.x=    2
((T2)this).x=   2
((T1)this).x=   1
((I)this).x=  0

The first step in processing a method invocation at compile time is to figure out the name of the method to be invoked and which type to search for definitions of methods of that name.

The name of the method is specified by the MethodName or Identifier which immediately precedes the left parenthesis of the MethodInvocation.

For the type to search, there are six cases to consider, depending on the form that precedes the left parenthesis of the MethodInvocation:

class Superclass {
  void foo() { System.out.println("Hi"); }
}

class Subclass1 extends Superclass {
  void foo() { throw new UnsupportedOperationException(); }

  Runnable tweak = new Runnable() {
    void run() {
      Subclass1.super.foo();  // Gets the 'println' behavior
    }
  };
}

interface Superinterface {
  default void foo() { System.out.println("Hi"); }
}

class Subclass2 implements Superinterface {
  void foo() { throw new UnsupportedOperationException(); }

  void tweak() {
    Superinterface.super.foo();  // Gets the 'println' behavior
  }
}

class Subclass3 implements Superinterface {
  void foo() { throw new UnsupportedOperationException(); }

  Runnable tweak = new Runnable() {
    void run() {
      Subclass3.Superinterface.super.foo();  // Illegal
    }
  };
}

The second step searches the type determined in the previous step for member methods. This step uses the name of the method and the argument expressions to locate methods that are both accessible and applicable, that is, declarations that can be correctly invoked on the given arguments.

There may be more than one such method, in which case the most specific one is chosen. The descriptor (signature plus return type) of the most specific method is the one used at run time to perform the method dispatch.

Certain argument expressions that contain implicitly typed lambda expressions (15.27.1) or inexact method references (15.13.1) are ignored by the applicability tests, because their meaning cannot be determined until the invocation's target type is selected. On the other hand, it is only argument expressions - not the invocation's target type - that influence the applicability tests, even if the method invocation expression is a poly expression.

The process of determining applicability begins by determining the potentially applicable methods (15.12.2.1). Then, to ensure compatibility with the Java programming language prior to Java SE 5.0, the process continues in three phases:

A method is applicable if it is applicable by one of strict invocation (the first phase, 15.12.2.2), loose invocation (the second phase, 15.12.2.3), or variable arity invocation (the third phase, 15.12.2.4). Deciding whether a method is applicable will, in the case of generic methods (8.4.4), require an analysis of the type arguments. Type arguments may be passed explicitly or implicitly; if they are passed implicitly, then bounds of the type arguments must be inferred from the argument expressions (18 (Type Inference)).

If several applicable methods have been identified during one of the three phases of applicability testing, then the most specific one is chosen, as specified in 15.12.2.5.

To check for applicability, the types of an invocation's arguments cannot, in general, be inputs to the analysis. This is because:

Instead, the input to the applicability check is a list of the arguments themselves. The arguments can be checked for compatibility with potential target types, even if the ultimate types of the arguments are unknown.

Note that overload resolution is independent of a target type. This is for two reasons:

class Doubler {
      static int two()    { return two(1); }
  private static int two(int i) { return 2*i;  }
}
class Test extends Doubler {	
  static long two(long j) { return j+j; }

  public static void main(String[] args) {
    System.out.println(two(3));
    System.out.println(Doubler.two(3)); // compile-time error
  }
}

class ColoredPoint {
  int x, y;
  byte color;
  void setColor(byte color) { this.color = color; }
}
class Test {
  public static void main(String[] args) {
    ColoredPoint cp = new ColoredPoint();
    byte color = 37;
    cp.setColor(color);
    cp.setColor(37);  // compile-time error
  }
}

void setColor(int color) { this.color = (byte)color; }

class Point { int x, y; }
class ColoredPoint extends Point { int color; }
class Test {
  static void test(ColoredPoint p, Point q) {
    System.out.println("(ColoredPoint, Point)");
  }
  static void test(Point p, ColoredPoint q) {
    System.out.println("(Point, ColoredPoint)");
  }
  public static void main(String[] args) {
    ColoredPoint cp = new ColoredPoint();
    test(cp, cp);  // compile-time error
  }
}

static void test(ColoredPoint p, ColoredPoint q) {
  System.out.println("(ColoredPoint, ColoredPoint)");
}

class Point { int x, y; }
class ColoredPoint extends Point { int color; }
class Test {
  static int test(ColoredPoint p) {
    return p.color;
  }
  static String test(Point p) {
    return "Point";
  }
  public static void main(String[] args) {
    ColoredPoint cp = new ColoredPoint();
    String s = test(cp);  // compile-time error
  }
}

package points;
public class Point {
  public int x, y;
  public Point(int x, int y) { this.x = x; this.y = y; }
  public String toString() { return toString(""); }
  public String toString(String s) {
    return "(" + x + "," + y + s + ")";
  }
}

package points;
public class ColoredPoint extends Point {
  public static final int
    RED = 0, GREEN = 1, BLUE = 2;
  public static String[] COLORS =
    { "red", "green", "blue" };

  public byte color;
  public ColoredPoint(int x, int y, int color) {
    super(x, y);
    this.color = (byte)color;
  }

  /** Copy all relevant fields of the argument into
    this ColoredPoint object. */
  public void adopt(Point p) { x = p.x; y = p.y; }

  public String toString() {
    String s = "," + COLORS[color];
    return super.toString(s);
  }
}

import points.*;
class Test {
  public static void main(String[] args) {
    ColoredPoint cp =
      new ColoredPoint(6, 6, ColoredPoint.RED);
    ColoredPoint cp2 =
      new ColoredPoint(3, 3, ColoredPoint.GREEN);
    cp.adopt(cp2);
    System.out.println("cp: " + cp);
  }
}

cp: (3,3,red)

public void adopt(ColoredPoint p) {
  adopt((Point)p);
  color = p.color;
}

cp: (3,3,red)

cp: (3,3,green)

public void adopt(Point p) {
  if (p instanceof ColoredPoint)
    color = ((ColoredPoint)p).color;
  x = p.x; y = p.y;
}

If there is a most specific method declaration for a method invocation, it is called the compile-time declaration for the method invocation.

It is a compile-time error if an argument to a method invocation is not compatible with its target type, as derived from the invocation type of the compile-time declaration.

If the compile-time declaration is applicable by variable arity invocation, then where the last formal parameter type of the invocation type of the method is F_n[], it is a compile-time error if the type which is the erasure of F_n is not accessible (6.6) at the point of invocation.

If the compile-time declaration is void, then the method invocation must be a top level expression (that is, the Expression in an expression statement or in the ForInit or ForUpdate part of a for statement), or a compile-time error occurs. Such a method invocation produces no value and so must be used only in a situation where a value is not needed.

In addition, whether the compile-time declaration is appropriate may depend on the form of the method invocation expression before the left parenthesis, as follows:

The compile-time parameter types and compile-time result are determined as follows:

A method is signature polymorphic if all of the following are true:

The following compile-time information is then associated with the method invocation for use at run time:

If the result of the invocation type of the compile-time declaration is not void, then the type of the method invocation expression is obtained by applying capture conversion (5.1.10) to the return type of the invocation type of the compile-time declaration.

At run time, method invocation requires five steps. First, a target reference may be computed. Second, the argument expressions are evaluated. Third, the accessibility of the method to be invoked is checked. Fourth, the actual code for the method to be executed is located. Fifth, a new activation frame is created, synchronization is performed if necessary, and control is transferred to the method code.

class Test1 {
  static void mountain() {
    System.out.println("Monadnock");
  }
  static Test1 favorite(){
    System.out.print("Mount ");
    return null;
  }
  public static void main(String[] args) {
    favorite().mountain();
  }
}

Mount Monadnock

class Test2 {
  public static void main(String[] args) {
    String s = "one";
    if (s.startsWith(s = "two"))
      System.out.println("oops");
  }
}

class Point {
  final int EDGE = 20;
  int x, y;
  void move(int dx, int dy) {
    x += dx; y += dy;
    if (Math.abs(x) >= EDGE || Math.abs(y) >= EDGE)
      clear();
  }
  void clear() {
    System.out.println("\tPoint clear");
    x = 0; y = 0;
  }
}
class ColoredPoint extends Point {
  int color;
  void clear() {
    System.out.println("\tColoredPoint clear");
    super.clear();
    color = 0;
  }
}

class Test1 {
  public static void main(String[] args) {
    Point p = new Point();
    System.out.println("p.move(20,20):");
    p.move(20, 20);

    ColoredPoint cp = new ColoredPoint();
    System.out.println("cp.move(20,20):");
    cp.move(20, 20);

    p = new ColoredPoint();
    System.out.println("p.move(20,20), p colored:");
    p.move(20, 20);
  }
}

p.move(20,20):
    Point clear
cp.move(20,20):
    ColoredPoint clear
    Point clear
p.move(20,20), p colored:
    ColoredPoint clear
    Point clear

class T1 {
  String s() { return "1"; }
}
class T2 extends T1 {
  String s() { return "2"; }
}
class T3 extends T2 {
  String s() { return "3"; }
  void test() {
    System.out.println("s()=\t\t"      + s());
    System.out.println("super.s()=\t"    + super.s());
    System.out.println("((T2)this).s()=\t" + ((T2)this).s());
    System.out.println("((T1)this).s()=\t" + ((T1)this).s());
  }
}
class Test2 {
  public static void main(String[] args) {
    T3 t3 = new T3();
    t3.test();
  }
}

s()=      3
super.s()=    2
((T2)this).s()= 3
((T1)this).s()= 3

abstract class C<T> {
  abstract T id(T x);
}
class D extends C<String> {
  String id(String x) { return x; }
}

C c = new D();
c.id(new Object());  // fails with a ClassCastException

Object id(Object x) { return id((String) x); }

The compile-time declaration of a method reference expression is the method to which the expression refers. In special cases, the compile-time declaration does not actually exist, but is a notional method that represents a class instance creation or an array creation. The choice of compile-time declaration depends on a function type targeted by the expression, just as the compile-time declaration of a method invocation depends on the invocation's arguments (15.12.3).

The search for a compile-time declaration mirrors the process for method invocations in 15.12.1 and 15.12.2, as follows:

It is a compile-time error if a method reference expression has the form ReferenceType :: [TypeArguments] Identifier, and the compile-time declaration is static, and ReferenceType is not a simple or qualified name (6.2).

It is a compile-time error if the method reference expression has the form super :: [TypeArguments] Identifier or TypeName . super :: [TypeArguments] Identifier, and the compile-time declaration is abstract.

It is a compile-time error if the method reference expression has the form super :: [TypeArguments] Identifier or TypeName . super :: [TypeArguments] Identifier, and the method reference expression occurs in a static context (8.1.3).

It is a compile-time error if the method reference expression has the form TypeName . super :: [TypeArguments] Identifier, and TypeName denotes a class C, and the immediately enclosing class or interface declaration of the method reference expression is not C or an inner class of C.

It is a compile-time error if the method reference expression has the form TypeName . super :: [TypeArguments] Identifier, and TypeName denotes an interface, and there exists a method, distinct from the compile-time declaration, that overrides the compile-time declaration from a direct superclass or direct superinterface of the class or interface whose declaration immediately encloses the method reference expression (8.4.8, 9.4.1).

It is a compile-time error if the method reference expression is of the form ClassType :: [TypeArguments] new and a compile-time error would occur when determining an enclosing instance for ClassType as specified in 15.9.2 (treating the method reference expression as if it were an unqualified class instance creation expression).

A method reference expression of the form ReferenceType :: [TypeArguments] Identifier can be interpreted in different ways. If Identifier refers to an instance method, then the implicit lambda expression has an extra parameter compared to if Identifier refers to a static method. It is possible for ReferenceType to have both kinds of applicable methods, so the search algorithm described above identifies them separately, since there are different parameter types for each case.

An example of ambiguity is:

interface Fun<T,R> { R apply(T arg); }

class C {
  int size() { return 0; }
  static int size(Object arg) { return 0; }

  void test() {
    Fun<C, Integer> f1 = C::size;
      // Error: instance method size()
      // or static method size(Object)?
  }
}

This ambiguity cannot be resolved by providing an applicable instance method which is more specific than an applicable static method:

interface Fun<T,R> { R apply(T arg); }

class C {
  int size() { return 0; }
  static int size(Object arg) { return 0; }
  int size(C arg) { return 0; }

  void test() {
    Fun<C, Integer> f1 = C::size;
      // Error: instance method size()
      // or static method size(Object)?
  }
}

The search is smart enough to ignore ambiguities in which all the applicable methods (from both searches) are instance methods:

interface Fun<T,R> { R apply(T arg); }

class C {
  int size() { return 0; }
  int size(Object arg) { return 0; }
  int size(C arg) { return 0; }

  void test() {
    Fun<C, Integer> f1 = C::size;
      // OK: reference is to instance method size()
  }
}

For convenience, when the name of a generic type is used to refer to an instance method (where the receiver becomes the first parameter), the target type is used to determine the type arguments. This facilitates usage like Pair::first in place of Pair<String,Integer>::first. Similarly, a method reference like Pair::new is treated like a "diamond" instance creation (new Pair<>()). Because the "diamond" is implicit, this form does not instantiate a raw type; in fact, there is no way to express a reference to the constructor of a raw type.

For some method reference expressions, there is only one possible compile-time declaration with only one possible invocation type (15.12.2.6), regardless of the targeted function type. Such method reference expressions are said to be exact. A method reference expression that is not exact is said to be inexact.

A method reference expression ending with Identifier is exact if it satisfies all of the following:

A method reference expression of the form ClassType :: [TypeArguments] new is exact if it satisfies all of the following:

A method reference expression of the form ArrayType :: new is always exact.

A method reference expression is compatible in an assignment context, invocation context, or casting context with a target type T if T is a functional interface type (9.8) and the expression is congruent with the function type of the ground target type derived from T.

The ground target type is derived from T as follows:

A method reference expression is congruent with a function type if both of the following are true:

If unchecked conversion was necessary for the compile-time declaration to be applicable, and this conversion would cause an unchecked warning in an invocation context, then a compile-time unchecked warning occurs, unless suppressed by @SuppressWarnings (9.6.4.5).

If unchecked conversion was necessary for the return type R', described above, to be compatible with the function type's return type, R, and this conversion would cause an unchecked warning in an assignment context, then a compile-time unchecked warning occurs, unless suppressed by @SuppressWarnings.

If a method reference expression is compatible with a target type T, then the type of the expression, U, is the ground target type derived from T.

It is a compile-time error if any class or interface mentioned by either U or the function type of U is not accessible (6.6) from the class or interface in which the method reference expression appears.

For each non-static member method m of U, if the function type of U has a subsignature of the signature of m, then a notional method whose method type is the function type of U is said to override m, and any compile-time error or unchecked warning specified in 8.4.8.3 may occur.

For each checked exception type X listed in the throws clause of the invocation type of the compile-time declaration, X or a superclass of X must be mentioned in the throws clause of the function type of U, or a compile-time error occurs.

The key idea driving the compatibility definition is that a method reference is compatible if and only if the equivalent lambda expression (x, y, z) -> exp.<T1, T2>method(x, y, z) is compatible. (This is informal, and there are issues that make it difficult or impossible to formally define the semantics in terms of such a rewrite.)

These compatibility rules provide a convenient facility for converting from one functional interface to another:

Task t = () -> System.out.println("hi");
Runnable r = t::invoke;

The implementation may be optimized so that when a lambda-derived object is passed around and converted to various types, this does not result in many levels of adaptation logic around the core lambda body.

Unlike a lambda expression, a method reference can be congruent with a generic function type (that is, a function type that has type parameters). This is because the lambda expression would need to be able to declare type parameters, and no syntax supports this; while for a method reference, no such declaration is necessary. For example, the following program is legal:

interface ListFactory {
  <T> List<T> make();
}

ListFactory lf  = ArrayList::new;
List<String> ls = lf.make();
List<Number> ln = lf.make();

At run time, evaluation of a method reference expression is similar to evaluation of a class instance creation expression, insofar as normal completion produces a reference to an object. Evaluation of a method reference expression is distinct from invocation of the method itself.

First, if the method reference expression begins with an ExpressionName or a Primary, this subexpression is evaluated. If the subexpression evaluates to null, a NullPointerException is raised, and the method reference expression completes abruptly. If the subexpression completes abruptly, the method reference expression completes abruptly for the same reason.

Next, either a new instance of a class with the properties below is allocated and initialized, or an existing instance of a class with the properties below is referenced. If a new instance is to be created, but there is insufficient space to allocate the object, evaluation of the method reference expression completes abruptly by throwing an OutOfMemoryError.

The value of a method reference expression is a reference to an instance of a class with the following properties:

The body of an invocation method depends on the form of the method reference expression, as follows:

If the body of the invocation method has the effect of a method invocation expression, then the compile-time parameter types and the compile-time result of the method invocation are determined as specified in 15.12.3. For the purpose of determining the compile-time result, the method invocation expression is an expression statement if the invocation method's result is void, and the Expression of a return statement if the invocation method's result is non-void.

The timing of method reference expression evaluation is more complex than that of lambda expressions (15.27.4). When a method reference expression has an expression (rather than a type) preceding the :: separator, that subexpression is evaluated immediately. The result of evaluation is stored until the method of the corresponding functional interface type is invoked; at that point, the result is used as the target reference for the invocation. This means the expression preceding the :: separator is evaluated only when the program encounters the method reference expression, and is not re-evaluated on subsequent invocations on the functional interface type.

It is interesting to contrast the treatment of null here with its treatment during method invocation. When a method invocation expression is evaluated, it is possible for the Primary that qualifies the invocation to evaluate to null but for no NullPointerException to be raised. This occurs when the invoked method is static (despite the syntax of the invocation suggesting an instance method). Since the applicable method for a method reference expression qualified by a Primary is prohibited from being static (15.13.1), the evaluation of the method reference expression is simpler - a null Primary always raises a NullPointerException.

The rules for evaluating expression names are given in 6.5.6.

A postfix expression followed by a ++ operator is a postfix increment expression.

The result of the postfix expression must be a variable of a type that is convertible (5.1.8) to a numeric type, or a compile-time error occurs.

The type of the postfix increment expression is the type of the variable. The result of the postfix increment expression is not a variable, but a value.

At run time, if evaluation of the operand expression completes abruptly, then the postfix increment expression completes abruptly for the same reason and no incrementation occurs. Otherwise, the value 1 is added to the value of the variable and the sum is stored back into the variable. Before the addition, binary numeric promotion (5.6) is performed on the value 1 and the value of the variable. If necessary, the sum is narrowed by a narrowing primitive conversion (5.1.3) and/or subjected to boxing conversion (5.1.7) to the type of the variable before it is stored. The value of the postfix increment expression is the value of the variable before the new value is stored.

Note that the binary numeric promotion mentioned above may include unboxing conversion (5.1.8).

A variable that is declared final cannot be incremented because when an access of such a final variable is used as an expression, the result is a value, not a variable. Thus, it cannot be used as the operand of a postfix increment operator.

A postfix expression followed by a -- operator is a postfix decrement expression.

The result of the postfix expression must be a variable of a type that is convertible (5.1.8) to a numeric type, or a compile-time error occurs.

The type of the postfix decrement expression is the type of the variable. The result of the postfix decrement expression is not a variable, but a value.

At run time, if evaluation of the operand expression completes abruptly, then the postfix decrement expression completes abruptly for the same reason and no decrementation occurs. Otherwise, the value 1 is subtracted from the value of the variable and the difference is stored back into the variable. Before the subtraction, binary numeric promotion (5.6) is performed on the value 1 and the value of the variable. If necessary, the difference is narrowed by a narrowing primitive conversion (5.1.3) and/or subjected to boxing conversion (5.1.7) to the type of the variable before it is stored. The value of the postfix decrement expression is the value of the variable before the new value is stored.

Note that the binary numeric promotion mentioned above may include unboxing conversion (5.1.8).

A variable that is declared final cannot be decremented because when an access of such a final variable is used as an expression, the result is a value, not a variable. Thus, it cannot be used as the operand of a postfix decrement operator.

A unary expression preceded by a ++ operator is a prefix increment expression.

The result of the unary expression must be a variable of a type that is convertible (5.1.8) to a numeric type, or a compile-time error occurs.

The type of the prefix increment expression is the type of the variable. The result of the prefix increment expression is not a variable, but a value.

At run time, if evaluation of the operand expression completes abruptly, then the prefix increment expression completes abruptly for the same reason and no incrementation occurs. Otherwise, the value 1 is added to the value of the variable and the sum is stored back into the variable. Before the addition, binary numeric promotion (5.6) is performed on the value 1 and the value of the variable. If necessary, the sum is narrowed by a narrowing primitive conversion (5.1.3) and/or subjected to boxing conversion (5.1.7) to the type of the variable before it is stored. The value of the prefix increment expression is the value of the variable after the new value is stored.

Note that the binary numeric promotion mentioned above may include unboxing conversion (5.1.8).

A variable that is declared final cannot be incremented because when an access of such a final variable is used as an expression, the result is a value, not a variable. Thus, it cannot be used as the operand of a prefix increment operator.

A unary expression preceded by a -- operator is a prefix decrement expression.

The result of the unary expression must be a variable of a type that is convertible (5.1.8) to a numeric type, or a compile-time error occurs.

The type of the prefix decrement expression is the type of the variable. The result of the prefix decrement expression is not a variable, but a value.

At run time, if evaluation of the operand expression completes abruptly, then the prefix decrement expression completes abruptly for the same reason and no decrementation occurs. Otherwise, the value 1 is subtracted from the value of the variable and the difference is stored back into the variable. Before the subtraction, binary numeric promotion (5.6) is performed on the value 1 and the value of the variable. If necessary, the difference is narrowed by a narrowing primitive conversion (5.1.3) and/or subjected to boxing conversion (5.1.7) to the type of the variable before it is stored. The value of the prefix decrement expression is the value of the variable after the new value is stored.

Note that the binary numeric promotion mentioned above may include unboxing conversion (5.1.8).

A variable that is declared final cannot be decremented because when an access of such a final variable is used as an expression, the result is a value, not a variable. Thus, it cannot be used as the operand of a prefix decrement operator.

The type of the operand expression of the unary + operator must be a type that is convertible (5.1.8) to a primitive numeric type, or a compile-time error occurs.

Unary numeric promotion (5.6) is performed on the operand. The type of the unary plus expression is the promoted type of the operand. The result of the unary plus expression is not a variable, but a value, even if the result of the operand expression is a variable.

At run time, the value of the unary plus expression is the promoted value of the operand.

The type of the operand expression of the unary - operator must be a type that is convertible (5.1.8) to a primitive numeric type, or a compile-time error occurs.

Unary numeric promotion (5.6) is performed on the operand.

The type of the unary minus expression is the promoted type of the operand.

At run time, the value of the unary minus expression is the arithmetic negation of the promoted value of the operand.

For integer values, negation is the same as subtraction from zero. The Java programming language uses two's-complement representation for integers, and the range of two's-complement values is not symmetric, so negation of the maximum negative int or long results in that same maximum negative number. Overflow occurs in this case, but no exception is thrown. For all integer values x, -x equals (~x)+1.

For floating-point values, negation is not the same as subtraction from zero, because if x is +0.0, then 0.0-x is +0.0, but -x is -0.0. Unary minus merely inverts the sign of a floating-point number. Special cases of interest:

The type of the operand expression of the unary ~ operator must be a type that is convertible (5.1.8) to a primitive integral type, or a compile-time error occurs.

Unary numeric promotion (5.6) is performed on the operand. The type of the unary bitwise complement expression is the promoted type of the operand.

At run time, the value of the unary bitwise complement expression is the bitwise complement of the promoted value of the operand. In all cases, ~x equals (-x)-1.

The type of the operand expression of the unary ! operator must be boolean or Boolean, or a compile-time error occurs.

The type of the unary logical complement expression is boolean.

At run time, the operand is subject to unboxing conversion (5.1.8) if necessary. The value of the unary logical complement expression is true if the (possibly converted) operand value is false, and false if the (possibly converted) operand value is true.

The binary * operator performs multiplication, producing the product of its operands.

Multiplication is a commutative operation if the operand expressions have no side effects.

Integer multiplication is associative when the operands are all of the same type.

Floating-point multiplication is not associative.

If an integer multiplication overflows, then the result is the low-order bits of the mathematical product as represented in some sufficiently large two's-complement format. As a result, if overflow occurs, then the sign of the result may not be the same as the sign of the mathematical product of the two operand values.

The result of a floating-point multiplication is determined by the rules of IEEE 754 arithmetic:

Despite the fact that overflow, underflow, or loss of information may occur, evaluation of a multiplication operator * never throws a run-time exception.

The binary / operator performs division, producing the quotient of its operands. The left-hand operand is the dividend and the right-hand operand is the divisor.

Integer division rounds toward 0. That is, the quotient produced for operands n and d that are integers after binary numeric promotion (5.6) is an integer value q whose magnitude is as large as possible while satisfying |d ⋅ q| ≤ |n|. Moreover, q is positive when |n| ≥ |d| and n and d have the same sign, but q is negative when |n| ≥ |d| and n and d have opposite signs.

There is one special case that does not satisfy this rule: if the dividend is the negative integer of largest possible magnitude for its type, and the divisor is -1, then integer overflow occurs and the result is equal to the dividend. Despite the overflow, no exception is thrown in this case. On the other hand, if the value of the divisor in an integer division is 0, then an ArithmeticException is thrown.

The result of a floating-point division is determined by the rules of IEEE 754 arithmetic:

Despite the fact that overflow, underflow, division by zero, or loss of information may occur, evaluation of a floating-point division operator / never throws a run-time exception.

The binary % operator is said to yield the remainder of its operands from an implied division; the left-hand operand is the dividend and the right-hand operand is the divisor.

In C and C++, the remainder operator accepts only integral operands, but in the Java programming language, it also accepts floating-point operands.

The remainder operation for operands that are integers after binary numeric promotion (5.6) produces a result value such that (a/b)*b+(a%b) is equal to a.

This identity holds even in the special case that the dividend is the negative integer of largest possible magnitude for its type and the divisor is -1 (the remainder is 0).

It follows from this rule that the result of the remainder operation can be negative only if the dividend is negative, and can be positive only if the dividend is positive. Moreover, the magnitude of the result is always less than the magnitude of the divisor.

If the value of the divisor for an integer remainder operator is 0, then an ArithmeticException is thrown.

class Test1 {
  public static void main(String[] args) {
    int a = 5%3;  // 2
    int b = 5/3;  // 1
    System.out.println("5%3 produces " + a +
               " (note that 5/3 produces " + b + ")");

    int c = 5%(-3);  // 2
    int d = 5/(-3);  // -1
    System.out.println("5%(-3) produces " + c +
               " (note that 5/(-3) produces " + d + ")");

    int e = (-5)%3;  // -2
    int f = (-5)/3;  // -1
    System.out.println("(-5)%3 produces " + e +
               " (note that (-5)/3 produces " + f + ")");

    int g = (-5)%(-3);  // -2
    int h = (-5)/(-3);  // 1
    System.out.println("(-5)%(-3) produces " + g +
               " (note that (-5)/(-3) produces " + h + ")");
  }
}

5%3 produces 2 (note that 5/3 produces 1)
5%(-3) produces 2 (note that 5/(-3) produces -1)
(-5)%3 produces -2 (note that (-5)/3 produces -1)
(-5)%(-3) produces -2 (note that (-5)/(-3) produces 1)

The result of a floating-point remainder operation as computed by the % operator is not the same as that computed by the remainder operation in IEEE 754, due to the choice of rounding policy in the Java programming language (15.4). The IEEE 754 remainder operation computes the remainder from a rounding division, not a truncating division, and so its behavior is not analogous to that of the usual integer remainder operator. Instead, the Java programming language defines % on floating-point operands to behave in a manner analogous to that of the integer remainder operator, with an implied division using the round toward zero rounding policy; this may be compared with the C library function fmod. The IEEE 754 remainder operation may be computed by the library routine Math.IEEEremainder or StrictMath.IEEEremainder.

The result of a floating-point remainder operation is determined by the following rules, which match IEEE 754 arithmetic except for how the implied division is computed:

Evaluation of a floating-point remainder operator % never throws a run-time exception, even if the right-hand operand is zero. Overflow, underflow, or loss of precision cannot occur.

class Test2 {
  public static void main(String[] args) {
    double a = 5.0%3.0;  // 2.0
    System.out.println("5.0%3.0 produces " + a);

    double b = 5.0%(-3.0);  // 2.0
    System.out.println("5.0%(-3.0) produces " + b);

    double c = (-5.0)%3.0;  // -2.0
    System.out.println("(-5.0)%3.0 produces " + c);

    double d = (-5.0)%(-3.0);  // -2.0
    System.out.println("(-5.0)%(-3.0) produces " + d);
  }
}

5.0%3.0 produces 2.0
5.0%(-3.0) produces 2.0
(-5.0)%3.0 produces -2.0
(-5.0)%(-3.0) produces -2.0

If only one operand expression is of type String, then string conversion (5.1.11) is performed on the other operand to produce a string at run time.

The result of string concatenation is a reference to a String object that is the concatenation of the two operand strings. The characters of the left-hand operand precede the characters of the right-hand operand in the newly created string.

The String object is newly created (12.5) unless the expression is a constant expression (15.29).

An implementation may choose to perform conversion and concatenation in one step to avoid creating and then discarding an intermediate String object. To increase the performance of repeated string concatenation, a Java compiler may use the StringBuffer class or a similar technique to reduce the number of intermediate String objects that are created by evaluation of an expression.

For primitive types, an implementation may also optimize away the creation of a wrapper object by converting directly from a primitive type to a string.

"The square root of 2 is " + Math.sqrt(2)

"The square root of 2 is 1.4142135623730952"

a + b + c

(a + b) + c

1 + 2 + " fiddlers"

"3 fiddlers"

"fiddlers " + 1 + 2

"fiddlers 12"

class Bottles {
  static void printSong(Object stuff, int n) {
    String plural = (n == 1) ? "" : "s";
  loop: while (true) {
      System.out.println(n + " bottle" + plural
          + " of " + stuff + " on the wall,");
      System.out.println(n + " bottle" + plural
          + " of " + stuff + ";");
      System.out.println("You take one down "
          + "and pass it around:");
      --n;
      plural = (n == 1) ? "" : "s";
      if (n == 0)
        break loop;
      System.out.println(n + " bottle" + plural
          + " of " + stuff + " on the wall!");
      System.out.println();
    }
    System.out.println("No bottles of " +
          stuff + " on the wall!");
  }

  public static void main(String[] args) {
    printSong("slime", 3);
  }
}

3 bottles of slime on the wall,
3 bottles of slime;
You take one down and pass it around:
2 bottles of slime on the wall!

2 bottles of slime on the wall,
2 bottles of slime;
You take one down and pass it around:
1 bottle of slime on the wall!

1 bottle of slime on the wall,
1 bottle of slime;
You take one down and pass it around:
No bottles of slime on the wall!

"You take one down and pass it around:"

The binary + operator performs addition when applied to two operands of numeric type, producing the sum of the operands.

The binary - operator performs subtraction, producing the difference of two numeric operands.

Binary numeric promotion is performed on the operands (5.6).

Note that binary numeric promotion may include unboxing conversion (5.1.8).

The type of an additive expression on numeric operands is the promoted type of its operands.

If this promoted type is int or long, then integer arithmetic is performed.

If this promoted type is float or double, then floating-point arithmetic is performed.

Addition is a commutative operation if the operand expressions have no side effects.

Integer addition is associative when the operands are all of the same type.

Floating-point addition is not associative.

If an integer addition overflows, then the result is the low-order bits of the mathematical sum as represented in some sufficiently large two's-complement format. If overflow occurs, then the sign of the result is not the same as the sign of the mathematical sum of the two operand values.

The result of a floating-point addition is determined by the rules of IEEE 754 arithmetic:

The binary - operator performs subtraction when applied to two operands of numeric type, producing the difference of its operands; the left-hand operand is the minuend and the right-hand operand is the subtrahend.

For both integer and floating-point subtraction, it is always the case that a-b produces the same result as a+(-b).

Note that, for integer values, subtraction from zero is the same as negation. However, for floating-point operands, subtraction from zero is not the same as negation, because if x is +0.0, then 0.0-x is +0.0, but -x is -0.0.

Despite the fact that overflow, underflow, or loss of information may occur, evaluation of a numeric additive operator never throws a run-time exception.

The type of each of the operands of a numerical comparison operator must be a type that is convertible (5.1.8) to a primitive numeric type, or a compile-time error occurs.

Binary numeric promotion is performed on the operands (5.6).

Note that binary numeric promotion may include unboxing conversion (5.1.8).

If the promoted type of the operands is int or long, then signed integer comparison is performed.

If the promoted type is float or double, then floating-point comparison is performed.

The result of a floating-point comparison, as determined by the specification of the IEEE 754 standard, is:

Subject to these considerations for floating-point numbers, the following rules then hold for integer operands or for floating-point operands other than NaN:

An instanceof expression may perform either type comparison or pattern matching.

If the operand to the right of the instanceof keyword is a ReferenceType, then the instanceof keyword is the type comparison operator.

If the operand to the right of the instanceof keyword is a Pattern, then the instanceof keyword is the pattern match operator.

The following rules apply when instanceof is the type comparison operator:

The following rules apply when instanceof is the pattern match operator: