What does "error: '.class' expected" mean and how do I fix it

Question

Occasionally, new users encounter the following rather obscure compilation error '.class' expected:

double d = 1.9;
int i = int d;  // error here
         ^
error: '.class' expected

Some Java IDE compilers state this slightly differently; e,g,

error: insert ". class" to complete Expression 

What do errors like this actually mean, what causes them, and how should you fix them?

Answer 1

First of all, this is a compilation error. If you see the message it at runtime, you are probably running code that has compilation errors.

Here are a couple of examples of the error:

double d = 1.9;
int i = int d;  // error here
         ^

int j = someFunction(int[] a);  // error here
                       ^

In both cases, the compiler error message will be error: '.class' expected.

What does the error message mean and what causes it?

The compiler has gotten rather confused during syntax checking by some code that is (frankly) nonsensical. The compiler has encountered a type (e.g. int or int[]) in a context where it was actually expecting an expression. It is then saying that the only symbols that would be syntactically acceptable at this point would be . followed by class.

Here is an example where this syntax would be correct;

Class<?> clazz = int;         // incorrect
Class<?> clazz = int.class;   // correct!

Note: It should always be possible to figure out why the compiler's syntax checker thinks the type should be an expression. However, it is often simpler to just treat this as "the compiler is confused" and look for the (inevitable!) syntax error that caused the confusion. That syntax error may not be obvious ... to a beginner ... but knowing that this is the root cause is a good start.

How do you fix it?

Unfortunately, the "suggestion" of adding .class is almost always incorrect. It certainly won't help in the two examples at the start of this Answer!

The actual fix depends on what you were trying to achieve by putting the type there.

• If you were intending to write a type cast, then you need to put parentheses (round brackets) around the type; e.g.

  double d = 1.9;
  int i = (int) d;   // Correct: casts `1.9` to an integer
  

• If you were simply intending to assign a value or pass a parameter as-is, then the type should be removed.

  int j = someFunction(a);  // Correct ... assuming that the type of
                            // 'a' is suitable for that call.
  

  You need to specify the type of a formal parameter when declaring a method. But you usually don't need to specify it for the actual argument. In the rare situations where you do (to resolve overload ambiguity), you use a type cast.

More examples

someMethod(array[]);

The error is reported on array[] because that is a type not an expression. The correction would probably be either:

someMethod(array);                  // pass ref to the entire array

or

someMethod(array[someExpression]);  // pass a single array element

---

int i = someMethod(int j); 

The programmer has put a parameter declaration into a method call. An expression is required here, not a declaration:

int i = someMethod(j);

---

int i = int(2.0);

The programmer was trying to do a typecast. It should be written like this:

int i = (int) 2.0;

---

int[]; letterCount = new int[26];

The programmer has added a spurious semicolon. It should be written like this:

int[] letterCount = new int[26];

---

if (someArray[] > 80) {
    // ...
}

The someArray[] denotes a type not an expression. The programmer probably means something like someArray[someIndex] > 80 or someArray.length > 80.

---

int[] integers = new int[arraySize];
...
return integers[];

The integers[] denotes a type declarator but an expression is required. It should be either

return integers;             // Return the entire array
                        

or

return integers[someIndex];  // Return one element of the array

---

if ((withdraw % 5 == 0) && (acnt_balc >= withdraw + 0.50))
    double cur = acnt_balc - (withdraw + 0.50);
    System.out.println(cur);
else
    System.out.println(acnt_balc);

The mistake here is that there should be curly brackets around the "then" statements.

if ((withdraw % 5 == 0) && (acnt_balc >= withdraw + 0.50)) {
    double cur = acnt_balc - (withdraw + 0.50);
    System.out.println(cur);
} else {
    System.out.println(acnt_balc);
}

But the compiler's confusion is that the "then" clause of the "if" cannot be a variable declaration. So the parser is looking for an expression that could be a method call. For example, the following would be locally syntactically valid:

if ((withdraw % 5 == 0) && (acnt_balc >= withdraw + 0.50))
    double.class.newInstance();   // no compilation error here

... albeit nonsensical in terms of what it tries to do. And of course the compiler would then trip over the dangling else.