maybe it's dumb but is there a difference between
new Something().method();
and
Something tmpSomething = new Something();
tmpSomething.method();
as I was calling only one method on this particular object, I chose the first solution but I'm not sure that this is exactly the same behavior...
I just want to mention the constructor initializes a Writer and method writes in this file...
I did a quick test. This is the extremely trivial test code:
public class TestLiveness
{
public static void test1()
{
System.out.println(new Square(4).square());
count();
}
public static void test2()
{
Square t = new Square(4);
System.out.println(t.square());
count();
}
private static void count()
{
for(int i=0; i<1000000; i++)
System.out.println(i);
}
static class Square
{
private int val;
Square(int val)
{
this.val = val;
}
int square()
{
return val * val;
}
}
}
Javap shows that the two methods are compiled differently; chaining doesn't touch the local variable table whereas the temporary variable does indeed stick around until the method returns. However, the VM/JIT compiler may still perform liveness analysis and allow the instance to be garbage collected before the method returns.
public static void test1();
Code:
0: getstatic #2; //Field java/lang/System.out:Ljava/io/PrintStream;
3: new #3; //class TestLiveness$Square
6: dup
7: iconst_4
8: invokespecial #4; //Method TestLiveness$Square."<init>":(I)V
11: invokevirtual #5; //Method TestLiveness$Square.square:()I
14: invokevirtual #6; //Method java/io/PrintStream.println:(I)V
17: invokestatic #7; //Method count:()V
20: return
public static void test2();
Code:
0: new #3; //class TestLiveness$Square
3: dup
4: iconst_4
5: invokespecial #4; //Method TestLiveness$Square."<init>":(I)V
8: astore_0
9: getstatic #2; //Field java/lang/System.out:Ljava/io/PrintStream;
12: aload_0
13: invokevirtual #5; //Method TestLiveness$Square.square:()I
16: invokevirtual #6; //Method java/io/PrintStream.println:(I)V
19: invokestatic #7; //Method count:()V
22: return
There is no difference whatsoever except that in the second case you have an unnecessary variable lying around that makes the code harder to maintain.
Also, objects that get created only to be discarded after calling a single method constitute a code smell.
They are the same. Although constructing an object and only calling a single method on it may indicate poor design. Why not allow Something.method(); without needing to expose a constructor?
Well, in the second case you've got the object tmpSomething so you can use it throughout in the code but in the first example you don't. So you can't.
I imagine the first method is probably a touch more efficient but probably not the best practice for Java conventions.
If you can get some value from the first call maybe you might want to define your method static:
public static ____ method() {
}
There is a subtle difference between the two snippets, but only when viewed within their scope. Consider them within methods:
public void doSomething1() {
new Something().method();
doSomeLongRunningSomething();
}
public void doSomething2() {
Something tmpSomething = new Something();
tmpSomething.method();
doSomeLongRunningSomething();
}
In the first method, the 'something' is immediately available for garbage collection while in the second method, tmpSomething stays within scope during the run of doSomeLongRunningSomething. If you are doing anything interesting during the finalize (e.g. closing the file), this could introduce some quirks.
That said, my preference is for the second example and naming the new instance as it assists the debugging processing. While stepping through code you have a named instance that is easier to watch. That doesn't apply when you're getting pre-existing instances in which case I find chaining methods more readable, e.g. myDog.getEyes().getLeftEye().getColorAsRgb().getRed().
Firstly I'll agree with everyone else and say they are the same in terms of function.
However, I'm of the opposite opinion on what most are saying in this post, which is that I think the first example is the way to go.
And with the first example, I'd extend it even further with some form of dependency injection. This will get you in the habit of giving you the ability to test things if you need to inject a mock/test version of that 'Something' class.
Also by not train wrecking (doing more than one operation on the one line which is a code smell, e.g. new dog().getEyes().getColour();), in my opinion improves readability as well as optimises your ability to refactor later on. Just because at the moment you only call that one method on that object doesn't mean you won't need that object to do something else on it later meaning you will have to extract a variable for that 'Something' object anyway.
Nothing wrong with that, even when you call only one function.
Have a look at Fluent Interfaces on Wikipedia or Fluent Interfaces by Martin Fowler
Related
For example consider the slide from the Google I/O '17 "Android Animations Spring to Life":
SpringForce force = new SpringForce(0)
.setDampingRation(0.4f)
.setStiffness(500f);
for (int i = 0; i < heads.getChildCount(); i++) {
View child = heads.getChildAt(i);
SpringAnimation anim;
anim = new SpringAnimation(child, DynamicAnimation.ROTATION);
anim.setSpring(force).setStartValue(-25).start();
}
There we can see that variable anim is defined on one line and the instance of the variable is created on the next line. Sometimes I also see that approach in some open source projects.
Is there a real benefit of using that approach or it is just a matter of style or readability? Or, in the case of slides, it is a matter of fitting the width of the slide? But if that's so they could have written something like:
SpringAnimation anim = new SpringAnimation(
child, DynamicAnimation.ROTATION);
Let's do a little experiment. Given the following two classes:
public class Test {
public static void main(String... args) {
Integer i = Integer.valueOf(1);
System.out.println(i);
}
}
public class Test2 {
public static void main(String... args) {
Integer i;
i = Integer.valueOf(1);
System.out.println(i);
}
}
we can take a look at the generated bytecode:
> javac *.java && javap -c *.class
Compiled from "Test.java"
public class Test {
public Test();
Code:
0: aload_0
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: return
public static void main(java.lang.String...);
Code:
0: iconst_1
1: invokestatic #2 // Method java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
4: astore_1
5: getstatic #3 // Field java/lang/System.out:Ljava/io/PrintStream;
8: aload_1
9: invokevirtual #4 // Method java/io/PrintStream.println:(Ljava/lang/Object;)V
12: return
}
Compiled from "Test2.java"
public class Test2 {
public Test2();
Code:
0: aload_0
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: return
public static void main(java.lang.String...);
Code:
0: iconst_1
1: invokestatic #2 // Method java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
4: astore_1
5: getstatic #3 // Field java/lang/System.out:Ljava/io/PrintStream;
8: aload_1
9: invokevirtual #4 // Method java/io/PrintStream.println:(Ljava/lang/Object;)V
12: return
}
Since the generated bytecode is identical, it is a matter of personal preference.
Altho everyone have a good point on readability and good coding standard, the example provided shows that there are some objects that have mandatory and optional fields.
The code above could easily be put together in the same "line" like this:
Obj o = new Obj([mandatory args])
.optionalParam1(...)
.optionalParam2(...);
But the decided to separate the mandatory from the optional, so its more readable and well organized (or at least thats what I think).
They have proven that it doesn't matter because the code is the same at the end, so it us up to you to decide which practices work for you and which doesn't (I like to heavily comment on my code so is easier to come back, but I only do it in my personal projects because my workteam doesn't find it valuable if the code is clean and self explanatory).
Both answers from #Turing85 and #Kavita_p are good and they provide enough context and information for you!
I am a novice to Java byte code and would like to understand the following byte code of Dispatch.class relative to Dispatch.java source code below :
Compiled from "Dispatch.java"
class Dispatch {
Dispatch();
Code:
0: aload_0
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: return
public static void main(java.lang.String[]);
Code:
0: new #2 // class B
3: dup
4: invokespecial #3 // Method B."<init>":()V
7: astore_1
8: aload_1
9: invokevirtual #4 // Method A.run:()V
12: return
}
//=====================Dispatch.java==============================
class Dispatch{
public static void main(String args[]){
A var = new B();
var.run(); // prints : This is B
}
}
//======================A.java===========================
public class A {
public void run(){
System.out.println("This is A");
}
}
//======================B.java===========================
public class B extends A {
public void run(){
System.out.println("This is B");
}
}
After doing some reading on the internet I had a first grasp of how JVM stack and opcodes work. I still however do not get what these command lines are good for :
3: dup //what are we duplicating here exactly?
4: invokespecial #3 //what does the #3 in operand stand for?
invokevirtual VS invokespecial //what difference there is between these opcodes?
It really sounds like you need to read the docs some more, but to answer your updated questions,
dup duplicates the top value on the operand stack. In this case, it would be the uninitialized B object that was pushed by the previous new instruction.
The #3 means that invokespecial is operating on the 3rd slot in the classfile's constant pool. This is where the method to be invoked is specified. You can see the constant pool by passing -c -verbose to javap.
invokevirtual is used for ordinary (non interface) virtual method calls. (Ignoring default interface methods for the moment) invokespecial is used for a variety of special cases - private method calls, constructor invocations, and superclass method calls.
In Java, is there a performance hit if i continually use nested get to retrieve values? For instance:
String firstname = getOffice().getDepartment().getEmployee().getFirstName();
String lastname = getOffice().getDepartment().getEmployee().getLastName();
String address = getOffice().getDepartment().getEmployee().getAddress();
VS:
Employee e = getOffice().getDepartment().getEmployee();
String firstname = e.getFirstName();
String lastname = e.getLastName();
String address = e.getAddress();
Would the 2nd version be faster because it has less 'jumps'?
It depends entirely on what the getXYZ calls do. If they're simple accessors to an underlying field, then no, not on HotSpot (Oracle's JVM), because they'll get optimized out if there's any need to do so. If, on the other hand, they do any kind of complex work (traversing a btree, etc.), then of course they'll have to do that work repeatedly (unless HotSpot can prove to itself that the calls are idempotent, which if the code has any complexity becomes unlikely). (Whether it matters that they do the work repeatedly is another question; until/unless you see an actual performance problem, don't worry about it.)
But the second is much more readable and maintainable. That's the more powerful reason for using it.
Rather than performance I see second as better human understandable code. You should not worry about micro optimizations but write a good and clean code.
The optimization you are thinking about is called premature optimization. You should not think about these unless you really have to.
I agree with #AmitD's answer about being the second one more readable. When chaining method calls like this, you can also write them in the following way -
Employee e = getOffice()
.getDepartment()
.getEmployee();
String firstname = e.getFirstName();
String lastname = e.getLastName();
String address = e.getAddress();
to further improve readability.
Possibly yes. But assuming the getters look like ordinary getters on the inside it will probably be so small that it becomes almost impossible to measure.
Also if you run through this code often enough to make it matter, the magic of the Hotspot compiler will kick in and mangle the byte code, probably again making both variations the same.
In the end it is extremely hard to tell what really will happen. If performance matters for you set up a test. If performance doesn't matter enough to justify the costs of the test ... well then it doesn't matter enough to worry.
Either use byte code analysis or time the two approaches using System.nanoTime. I think second one is faster. here is what I did to conclude this:
I wrote three classes as given below:
public static class A {
public B b = new B();
}
public static class B {
public E e = new E();
}
public static class E {
public String name = "s";
public int age = 1;
}
Then I wrote two simple methods and get their java byte code using javap -c CLASS_NAME.
public static void Test1() {
A a = new A();
String str = a.b.e.name;
int age = a.b.e.age;
}
The byte code of above method is:
public static void Test1();
Code:
// new A();
0: new #15
3: dup
4: invokespecial #17
7: astore_0
8: aload_0
// a.b (it accesses the field and put it on operand stack)
9: getfield #18
// b.e
12: getfield #22
// b.name
15: getfield #28
// pop 'name' from stack
18: astore_1
19: aload_0
// cyle continues
20: getfield #18
23: getfield #22
26: getfield #34
29: istore_2
30: return
You can clearly see at byte code level, each time you try to access field, it put the value of that filed on stack and then this cycle continues. Therefore, a.a1.a2....an would be n instruction if stack would have enough spae to hold all n. And there was no optimisation by compiler this same cycle of called again to access both name and age field.
Now here is the second method:
public static void Test2() {
A a = new A();
E e = a.b.e;
String str = e.name;
int age = e.age;
}
Byte code for above method is:
public static void Test2();
Code:
// new A();
0: new #15
3: dup
4: invokespecial #17
7: astore_0
8: aload_0
// store a.b.e on operand stack once
9: getfield #18
12: getfield #22
15: astore_1
16: aload_1
// get 'name' field
17: getfield #28
20: astore_2
21: aload_1
// get 'age' field
22: getfield #34
25: istore_3
26: return
Above is 4 instruction shorter than previous code as it prevents execution of getfield. So I think this should be faster than previous one.
I've been reading up on the Java Virtual Machine Instruction Set and noticed that when using instructions to invoke methods (e.g. invokestatic, invokevirtual, etc.) that are marked synchronized, it's up to that particular bytecode instruction to acquire the monitor on the receiver object. Similarly, when returning from a method, it's up to the instruction that leaves the method to release the monitor when the method is synchronized. This seems strange, given that there are explicit monitorenter and monitorexit bytecodes for managing monitors. Is there a particular reason for the JVM designing these instructions this way, rather than just compiling the methods to include the monitorenter and monitorexit instructions where appropriate?
Back in the mid-90s, there were no Java JIT compilers and micro-synchronisation was thought to be a really great idea.
So you are calling these synchronised method a lot. Even Vector has 'em! You could deal without the extra bytecodes to interpret.
But not just when the code is being run. The class file is bigger. Extra instructions, but also setting up the try/finally tables and verification that something naughty hasn't been slipped in.
Just my guess.
Are you asking why are there two ways of doing the same thing?
When a method is market as synchronized, it would be redundant to also have monitorenter/exit instructions. If it only had monitorenter/exit instruction you would not bet able to see externally that the method is synchronized (without reading the actual code)
There are more than a few examples of two or more ways of doing the same thing. Each has relative strengths and weaknesses. (e.g. many of the single byte instructions are short versions of a two byte instruction)
EDIT: I must be missing something in the question because the caller doesn't need to know if the callee is synchronized
public static void main(String... args) {
print();
printSynchronized();
printSynchronizedInternally();
}
public static void print() {
System.out.println("not synchronized");
}
public static synchronized void printSynchronized() {
System.out.println("synchronized");
}
public static void printSynchronizedInternally() {
synchronized(Class.class) {
System.out.println("synchronized internally");
}
}
produces the code
public static void main(java.lang.String[]);
Code:
0: invokestatic #2; //Method print:()V
3: invokestatic #3; //Method printSynchronized:()V
6: invokestatic #4; //Method printSynchronizedInternally:()V
9: return
public static void print();
Code:
0: getstatic #5; //Field java/lang/System.out:Ljava/io/PrintStream;
3: ldc #6; //String not synchronized
5: invokevirtual #7; //Method java/io/PrintStream.println:(Ljava/lang/String;)V
8: return
public static synchronized void printSynchronized();
Code:
0: getstatic #5; //Field java/lang/System.out:Ljava/io/PrintStream;
3: ldc #8; //String synchronized
5: invokevirtual #7; //Method java/io/PrintStream.println:(Ljava/lang/String;)V
8: return
public static void printSynchronizedInternally();
Code:
0: ldc_w #9; //class java/lang/Class
3: dup
4: astore_0
5: monitorenter
6: getstatic #5; //Field java/lang/System.out:Ljava/io/PrintStream;
9: ldc #10; //String synchronized internally
11: invokevirtual #7; //Method java/io/PrintStream.println:(Ljava/lang/String;)V
14: aload_0
15: monitorexit
16: goto 24
19: astore_1
20: aload_0
21: monitorexit
22: aload_1
23: athrow
24: return
Exception table:
from to target type
6 16 19 any
19 22 19 any
}
<speculation>
By delegating lock management onto the caller, some optimizations are now possible. For example, suppose you have a class like this:
public class Foo {
public synchronized void bar() {
// ...
}
}
And suppose it is used by this caller class:
public class Caller {
public void call() {
Foo foo = new Foo();
// implicit MONITORENTER on foo's lock
foo.bar();
// implicit MONITOREXIT on foo's lock
}
}
Based on escape analysis, the JVM knows that foo never escapes the thread. Because of this, it can avoid the implicit MONITORENTER and MONITOREXIT instructions.
Avoiding unnecessary locks may have been more performance-driven in earlier days of the JVM when speed was a rare commodity.
</speculation>
Are you asking why synchronised methods use explicit monitor entry and exit instruction when the JVM could infer them by looking at the method's attributes?
I would guess it is because, as well as methods it is possible to synchronise arbitrary blocks of code:
synchronized( some_object ){ // monitorentry some_object
System.out.println("I am synchronised!");
} // monitorexit some_object
Therefore it makes sense to use the same instructions for both synchronised methods and synchronised blocks.
Was searching on the same question, and came across the following article. Looks like method level synchronization generates slightly more efficient byte code than block level synchronization. For block level synchronization, explicit byte code is generated to handle exceptions which is not done for method level synchronization. So a possible answer could be, these two ways are used to make method level synchronization slightly faster.
http://www.ibm.com/developerworks/ibm/library/it-haggar_bytecode/
One common dilemma I have faced throughout programming is regarding declaring variables inside a loop. Say I have to perform something like the following:
List list=myObject.getList();
Iterator itr=list.iterator();
while (itr.hasNext()){
BusinessObject myBo=(BusinessObject)itr.next();
process(myBo);
}
In the above snippet, should myBo be declared outside the loop or does declaring it inside the loop not cause harm to memory and performance?
Declaring it inside the loop won't cause any harm to the memory and performance.
If possible use List<BusinessObject> and Iterator<BusinessObject> to avoid casting:
List<BusinessObject> list = myObject.getList();
Iterator<BusinessObject> itr = list.iterator();
while (itr.hasNext()) {
process(itr.next());
}
One principle of good software design is to limit the scope of local variables, i.e. to declare them just in time within a block that ends soon after the last use of that variable. This doesn't affect performance or other "hard" aspects but makes the program more readable and easier to analyze.
In summary, doing what you're doing is considered GOOD.
myBo is simply a reference to an object (that is returned by itr.next()). As such the amount of memory that it needs is very small, and only created once, and adding it inside the loop should not affect your program. IMO, declaring it inside the loop where it is used actually helps make it more readable.
The most elegant solution for your loop would be an enhanced for loop (java 5 or newer):
List<BusinessObject> list = myObject.getList();
for( BusinessObject myBo : list ) {
process(myBo);
}
But even with the code you provided there will be no performance problem, because all the temporary variables only hold references to the BusinessObject, which is very cheap.
It doesn't cause any memory harm.
BTW unless you're omitting some code you may skip the declaration altogether:
while (itr.hasNext()){
//BusinessObject myBo=(BusinessObject)itr.next();
process((BusinessObject)itr.next());
}
If short -- no.
In C++ it could be a problem if myBo is created by copying
but in Java there is always used references, is'nt it?
for performance, its better to optimize something you are do in process()
Just have a look at the byte code with javap -c [ClassName]. Here's a class demonstrating a few examples of single-use variables with loops. The relevant bytecode dump is in the comments:
class HelloWorldLoopsAnnotated {
//
// HelloWorldLoopsAnnotated();
// Code:
// 0: aload_0
// 1: invokespecial #1; //Method java/lang/Object."<init>":()V
// 4: return
////////////////////////////////////////////////////////////////////////////
void stringDeclaredInsideLoop(){
while (true) {
// 0: ldc #2; //String Hello World!
String greeting = "Hello World!";
doNothing(greeting);
}
}
//
// void stringDeclaredInsideLoop();
// Code:
// 0: ldc #2; //String Hello World!
// 2: astore_1
// 3: aload_0
// 4: aload_1
// 5: invokespecial #3; //Method doNothing:(Ljava/lang/String;)V
// 8: goto 0
////////////////////////////////////////////////////////////////////////////
void stringDeclaredOutsideLoop(){
String greeting;
while (true) {
greeting = "Hello World!";
doNothing(greeting);
}
}
//
// void stringDeclaredOutsideLoop();
// Code:
// 0: ldc #2; //String Hello World!
// 2: astore_1
// 3: aload_0
// 4: aload_1
// 5: invokespecial #3; //Method doNothing:(Ljava/lang/String;)V
// 8: goto 0
////////////////////////////////////////////////////////////////////////////
void stringAsDirectArgument(){
while (true) {
doNothing("Hello World!");
}
}
// void stringAsDirectArgument();
// Code:
// 0: aload_0
// 1: ldc #2; //String Hello World!
// 3: invokespecial #3; //Method doNothing:(Ljava/lang/String;)V
// 6: goto 0
////////////////////////////////////////////////////////////////////////////
private void doNothing(String s) {
}
}
stringDeclaredInsideLoop() and stringDeclaredOutsideLoop() yield identical six-instruction bytecode. stringDeclaredInsideLoop() does still win: limited scope is best.
After some contemplation, I can't really see how tightening scope would ever affect performance: identical data in the stack would necessitate identical instructions.
stringAsDirectArgument(), however, defines the operation in only four instructions. Low memory environments (e.g. my magnificently dumb phone) may appreciate the optimization while a colleague reading your code may not, so exercise judgement before shaving bytes from your code.
See the full gist for more.
The temporary reference myBo is put on stack and should mostly be optimized away. There shouldn't be any performance penalty in your code.