The official docs just say
14.6. The Empty Statement
An empty statement does nothing.
(https://docs.oracle.com/javase/specs/jls/se7/html/jls-14.html#jls-14.6)
Are statements like ;;;;;;;;;;; actually compiled by the Java compiler?
If so, do these statements take time to be executed, like a nop?
In short: does an empty statement really do "nothing"?
The java compiler does nothing with these statements. Hence, they are ignored.
The following method
public static void test(){
;;;;;;;;
}
just compiles to the following Bytecode:
public static void test();
descriptor: ()V
flags: ACC_PUBLIC, ACC_STATIC
Code:
stack=0, locals=0, args_size=0
0: return
LineNumberTable:
line 39: 0
Compilers just use NOPs in certain compilation strategies.
Related
I changed the compilation of a project from Ant to Maven. We still use Java 1.7.0_80. The ByteCode of all classes stayed the same except for a Comparator class. I disassembled the class with javap -c. The only differences are in #-values, e.g.:
before: invokevirtual #2
after: invokevirtual #29
What do these #-values mean? Is this a functional difference or just a difference in naming?
EDIT: The first method in Bytecode before and after:
public de.continentale.kvrl.model.comp.KvRLRechBetragEuroComparator();
Code:
0: aload_0
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: return
public de.continentale.kvrl.model.comp.KvRLRechBetragEuroComparator();
Code:
0: aload_0
1: invokespecial #21 // Method java/lang/Object."<init>":()V
4: return
The #29 refers to an index in the constant table that describes the method being invoked. It would have been better if you had pasted the full output of javap -c, because the comment at the end of the line indicates the actual method descriptor.
Example of javap -c on an invocation of an instance method test in class Z:
7: invokevirtual #19 // Method snippet/Z.test:()V
You can ignore the # number, as long as the method descriptor in the comment is the same.
Why
As to the "why" question, it is very likely caused by the debug in the ant and maven compiler task/plugin settings.
By default, the maven-compiler-plugin compiles with the debug configuration option set to true, which will attach among other the name of the source file, and thing like line number tables and local variable names.
https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html
By default, the ant java compiler has this set to false.
https://ant.apache.org/manual/Tasks/javac.html
To compare and check, set the debug parameter of the Ant Javac task to true and see if that makes the generated .class files the same.
In putty I am attempting to create a Jasmin program that, when assembled and ran as a Java program, will output the integer "431". When I attempt to assemble the program the console says there is a syntax error on line 11. I am having trouble figuring out what it is. Here is my code:
.class public Lab3_JasminExample
.super java/lang/Object
.method public <init>()V
aload_0
invokespecial java/lang/Object/<init>()V
return
.end method
.method public static main ([Ljava.lang.String;)V
.limit stack 10
.limit locals 10
getstatic java/lang/System/out Ljava/io/PrintStream;
sipush 431
invokevirtual java/io/PrintStream/println(I)V
return
.end method
Line 11 would be ".limit stack 10" and I can't see what is wrong with how I wrote that. What am I doing incorrectly?
Errors may be reported on a line but be triggered by previous (or following!) lines, so always look around the offending line.
My Jasmin (version 2.4) correctly reports the error on line 10
a.j:10: Warning - Syntax error.
.method public static main ([Ljava.lang.String;)V
^
This is a silly mistake really: there is space between the method name (main) and its descriptor (([Ljava.lang.String;)V)
Line 10 should be .method public static main([Ljava.lang.String;)V
I am currently writing my own compiler and I am trying to compile the following code:
List[String] list = List("a", "b", "c", "d")
list stream map((String s) => s.toUpperCase())
System out println list
The compiler has no problem parsing, linking or compiling the code, but when it comes to executing it, the JVM throws the following error:
java.lang.VerifyError: Illegal type at constant pool entry 40 in class dyvil.test.Main
Exception Details:
Location:
dyvil/test/Main.main([Ljava/lang/String;)V #29: invokevirtual
Reason:
Constant pool index 40 is invalid
Bytecode:
...
I tried to use javap to find the problem, and this is the instruction #29:
29: invokevirtual #40 // InterfaceMethod java/util/Collection.stream:()Ljava/util/stream/Stream;
And the entry in the Constant Pool (also using javap):
#37 = Utf8 stream
#38 = Utf8 ()Ljava/util/stream/Stream;
#39 = NameAndType #37:#38 // stream:()Ljava/util/stream/Stream;
#40 = InterfaceMethodref #36.#39 // java/util/Collection.stream:()Ljava/util/stream/Stream;
When opening the class with the Eclipse Class File Viewer, the line where #29 should be reads:
Class Format Exception
and all following instructions are not shown anymore (except for Locals, ...). However, the ASM Bytecode Plugin writes
INVOKEVIRTUAL java/util/Collection.stream ()Ljava/util/stream/Stream;
at that line, which appears to be valid. What am I doing wrong / missing here?
I figured out my mistake. The error lies here:
invokevirtual #40 // InterfaceMethod
^^^^^^^ ^^^^^^^^^
I am using invokevirtual on an interface method, which is generally not a good idea. However I think that the error thrown by the verifier should be a bit more clear about what is actually wrong.
With ASM you will see this error because of an incorrect isInterface flag. The argument isInterface of visitMethodInsn refers to the target/owner/destination and not the current context.
i.o.w when using INVOKEVIRTUAL, isInterface is false.
see issue here for more details.
I used MAT tool in Eclipse to investigate a memory leak issue. I found that the leak was caused by an anonymous inner class instance in my app. The class name displayed in MAT is com.mycompany.myproduct.MyActivity$3. There are many anonymous inner classes defined in MyActivity.java. How do I know the which inner class com.mycompany.myproduct.MyActivity$3 indicates?
Thanks.
On the Oracle compiler, they're numbered in order of occurrence in the class. I'm not sure if that's part of any specification or consistent with other implementations.
You could decompile the class--JD-GUI is a great tool for that--and then you'll see what you want to know. You could even just go with basic disassembly using javap -c. It'll give you a rough idea of where the classes occur.
Hint: debugger somehow knows which classes are where. So you can, too!
Try using javap on this example with two anonymous classes:
import java.util.*;
public class Test {
public static void main(String [] args) {
Map m = new HashMap(){{System.out.print(1);}};
Map m1 = new HashMap(){{System.out.print(2);}};
}
}
Compile it and run javap -c -l:
$ javap -c -l Test
Compiled from "Test.java"
public class Test extends java.lang.Object{
public Test();
Code:
0: aload_0
1: invokespecial #1; //Method java/lang/Object."<init>":()V
4: return
LineNumberTable:
line 3: 0
public static void main(java.lang.String[]);
Code:
0: new #2; //class Test$1
3: dup
4: invokespecial #3; //Method Test$1."<init>":()V
7: astore_1
8: new #4; //class Test$2
11: dup
12: invokespecial #5; //Method Test$2."<init>":()V
15: astore_2
16: return
LineNumberTable:
line 5: 0
line 7: 8
line 9: 16
}
As you can see, the first class got name Test$1, the second one—Test$2. Hope tat helps.
For more specific information, decompile the specific classes you're interested in, e.g. javap -c -l Test\$2. Pay attention to line numbers: they will give you a hint on where in the source file the class was defined.
When you compile your code securely you have MyActivity$1.class, MyActivity$2.class, MyActivity$3.class, and so on. You can use a java decompiler (over your .class) in order to identify the anonymus class that is throwing the exception.
The whole point of anonymous classes is that they are just that. As you have found its not easy to figure out which one its come from. Usually the numbering starts at one, so my guess is that it will be the third declared anonymous class that is your problem.
In this situation, you maybe better off to refactor your code to not have any anonymous classes. Otherwise I suggest attaching the debugger and stepping the code.
I was experimenting with enum, and I found that the following compiles and runs fine on Eclipse (Build id: 20090920-1017, not sure exact compiler version):
public class SwitchingOnAnull {
enum X { ,; }
public static void main(String[] args) {
X x = null;
switch(x) {
default: System.out.println("Hello world!");
}
}
}
When compiled and run with Eclipse, this prints "Hello world!" and exits normally.
With the javac compiler, this throws a NullPointerException as expected.
So is there a bug in Eclipse Java compiler?
This is a bug. Here's the specified behavior for a switch statement according to the Java Language Specification, 3rd Edition:
JLS 14.11 The switch Statement
SwitchStatement:
switch ( Expression ) SwitchBlock
When the switch statement is executed, first the Expression is evaluated. If the Expression evaluates to null, a NullPointerException is thrown and the entire switch statement completes abruptly for that reason.
Apparently the bug in Eclipse has nothing to do with default case or enum at all.
public class SwitchingOnAnull {
public static void main(String[] args) {
java.math.RoundingMode x = null;
switch(x) {};
switch((Integer) null) {};
switch((Character) null) {
default: System.out.println("I've got sunshine!");
}
}
}
The above code compiles and runs "fine" on (at least some version of) Eclipse. Each individual switch throws a NullPointerException when compiled with javac, which is exactly as the specification mandates.
The cause
Here's javap -c SwitchingOnAnull when compiled under Eclipse:
Compiled from "SwitchingOnAnull.java"
public class SwitchingOnAnull extends java.lang.Object{
public SwitchingOnAnull();
Code:
0: aload_0
1: invokespecial #8; //Method java/lang/Object."<init>":()V
4: return
public static void main(java.lang.String[]);
Code:
0: aconst_null
1: astore_1
2: getstatic #16; //Field java/lang/System.out:Ljava/io/PrintStream;
5: ldc #22; //String I've got sunshine!
7: invokevirtual #24; //Method java/io/PrintStream.println:(Ljava/lang/String;)V
10: return
}
It seems that the Eclipse compiler gets rid of the entire switch constructs entirely. Unfortunately this optimization breaks the language specification.
The official words
The bug has been filed and assigned for fix.
Olivier Thomann 2010-05-28 08:37:21 EDT
We are too aggressive on the optimization.
For:
switch((Integer) null) {};
we optimize out the whole switch statement when we should at least evaluate the
expression.
I'll take a look.
Candidate for 3.6.1.
See also
Bug 314830 - Switching on a null expression doesn't always throw NullPointerException
Definitly. If we look at the chapter 14.11 of the java language specification, it clearly states (under 'discussion'):
The prohibition against using null as
a switch label prevents one from
writing code that can never be
executed. If the switch expression is
of a reference type, such as a boxed
primitive type or an enum, a run-time
error will occur if the expression
evaluates to null at run-time.
Yep. According to the JLS it's a bug:
If the switch expression is of a reference type, such as a boxed primitive type or an enum, a run-time error will occur if the expression evaluates to null at run-time.