Código Java válido que NO es un código Groovy válido?

Bien, aquí hay un punto:

int[] i = { 0, 1, 2 };

Esa es una buena sintaxis en java, mala en groovy.

No creo que quieras asumir que cualquier código java será equivalente en groovy. Este sitio describe algunas de las diferencias, que incluye cosas tan básicas como == no significa lo mismo en ambos idiomas. Además, la inicialización de matrices estáticas es diferente, y no hay clases internas anónimas.

Esto compila bien en Java 1.6

public class Test2 {
    int[] i = { 0, 1, 2 };

    private class Class1 {
        public void method1() {
            if (i[2] == 2) {
                System.out.println("this works");
            }
        }
    }

    public void method1() {
        Class1 class1 = new Class1();
        class1.method1();
    }
}

Pero está tan equivocado en Groovy. Da los siguientes errores en Groovy 1.6:

unexpected token: 1 @ line 2, column 14.

Class definition not expected here. Possible attempt to use inner class. Inner classes not supported, perhaps try using a closure instead. at line: 4 column: 2.

Si arreglas esas cosas, imprime lo que esperas, sin embargo.

Si está buscando problemas de sintaxis del lenguaje más nuevos, como genéricos o anotaciones, Groovy admite ambos, aunque no del todo.

Matrices multidimensionales, donde no se especifica el tamaño.

def x=new Object[5][];  // ERROR: expression expected 

def x=new Object[5][2]; // this works

Todo lo que puedo pensar por ahora:

• int def;
• String s = "$$";

Complementando la respuesta de Peter Dolberg:

Además del código Java válido que no es válido en Groovy, también debe tener cuidado con el código que es válido tanto en Java como en Groovy, pero que tiene resultados diferentes en Groovy. Ejemplos obvios son los literales char y gStrings:

System.out.println(String.valueOf('3' + 3)); // 54 in Java, 33 in Groovy (arithmetic ascii value vs. String concat)

System.out.println("${3+4}");

Accesos implícitos:

class Foo {public static int counter; public static int bar; public static void getBar() {counter++; return bar;}}
System.out.println(Foo.bar);
System.out.println(Foo.counter); // 0 in Java, 1 in Groovy

ToString() ha sido sobrescrito por GroovyDefaultMethods, que puede morder al analizar el resultado.

Map someMap = new HashMap();
someMap.put("a", "b")
someMap.toString();

La operación es igual a

"foo" == "foo"
class Foo {public boolean equals() {return true;}}
new Foo() == new Foo()

Algunos precedencia del operador:

a *= b/100; // Groovy: (a *= b)/100; Java: a *= (b/100);

Esta no es una respuesta correcta a la pregunta original, ya que el código groovy todavía es sintácticamente válido en sí mismo, pero ya que tiene un resultado diferente, creo que vale la pena mencionarlo aquí. El resultado es que algorítmicamente, un método puede devolver el resultado incorrecto(no válido) cuando se copia de Java a Groovy.

Bloques de inicialización no estáticos:

class Foo {
  Integer x;   
  { x = 1; }
}

ACTUALIZACIÓN: Este es de hecho un código Groovy válido.

¿Alguien ha mencionado la diferencia en ==? Tomé esto de la documentación de Grails.

== significa igual en todos los tipos. En Java hay una parte wierd de la sintaxis donde = = significa igualdad para tipos primitivos y = = significa identidad para objetos.

Declarar una matriz de un tipo dado usando [] después del nombre de la variable en lugar del tipo funciona en Java pero no Groovy.

byte[] buff = new byte[1024]; // Works

byte buff[] = new byte[1024]; // Not Groovy

Resulta en un tipo primitivo literal: byte no se puede usar como nombre de método