Q:

What scala statements or code can produce a byte-code which can not be translated to java? 

I have read an answer to a question about converting Scala code to Java code.  It says:
I don't think it's possible to convert from scala back to standard java since Scala does some pretty low-level byte-code manipulation.  I'm 90% sure they do some things that can't exactly be translated back into normal Java code. 
So what Scala statements or code can produce bytecode which can not be translated to java? 
P.S. I generally agree with that answer, but want a concrete example for learning purposes. 

A:

The answer really depends on how hard you want to try to convert the code. 
Since Java and Scala are both turing complete, any program in one can trivially be converted to the other, but this isn't really interesting or useful. 
What you really want is to convert the results to readable, idiomatic code.  From this perspective, even Java code can't automatically be converted to Java because compilation loses information (though relatively little compared to C) and machines aren't as good as humans at writing human readable code anyway. 
If you got a Java and Scala expert, they could probably rewrite your Scala codebase in Java and end up with reasonably idiomatic Java code.  But it wouldn't be as readable as Scala due to the simple fact that Scala is a language designed to improve on Java.  Scala tries to remove the warts from Java and provide powerful high level programming features, removing the need for all the classic Java boilerplate.  So the Java equivalent codebase will not be as readable. 
From this perspective, the answer is "any feature in Scala that is not in Java". 

A:

Scala's nested blocks do not have a Java equivalent. 
Nested block in Scala (taken from this question):
def apply(x: Boolean) = new Tuple2(null, {
  while (x) { }
  null
})

Produces the bytecode
 0: new           #12                 // class scala/Tuple2
 3: dup           
 4: aconst_null   
 5: iload_1       
 6: ifne          5
 9: aconst_null   
10: invokespecial #16                 // Method scala/Tuple2."<init>":(Ljava/lang/Object;Ljava/lang/Object;)V
13: areturn   

At instruction 0 an uninitialised object is pushed onto the stack, and then initialised at instruction 10.  Between these two points there is a backwards jump from 6 to 5.  This actually reveals a bug in the OpenJDK bytecode verifier as it rejects this code despite the fact that it is acceptable by the JVM specifications.  This probably got through testing as this bytecode can't be generated from Java. 
As in Java nested blocks are not expressions that evaluate to a value then the the closest Java equivalent would be 
public Tuple2 apply(boolean x){
  while(x){}
  return new Tuple2(null,null);
}

Which would compile to something akin to
 0: iload_1
 1: ifne          0
 3: new           #12                 // class scala/Tuple2
 6: dup
 7: aconst_null
 8: dup
 9: invokespecial #16                 // Method scala/Tuple2."<init>":(Ljava/lang/Object;Ljava/lang/Object;)V
12: areturn

Note that this doesn't have the uninitialised object on the stack at the time of the backwards jump. ( N.B. bytecode was written by hand, do not execute!) 

This paper from Li, White, and Singer shows differences in JVM languages including the bytecode that they compile to.  It finds that in an N-gram analysis of bytecodes that 58.5% of 4-grams executed by Scala are not found in bytecode executed by Java.  This is not to say that Java can't produce these bytecodes, but that they weren't present in the Java corpus.