Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Performance issue with synthetic accessor method  RSS feed

 
Mihai Radulescu
Ranch Hand
Posts: 918
IntelliJ IDE Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hallo,

Sometime in my code I use the fallow construction :

It is something wrong with this code ?
I don't see any problem but when I use Eclipse with the warnings activated(Project->Properties->Java Compiler->Error&Warnings) I get the fallow warning :

"Read access to enclosing field Extern.extern is emulated by a synthetic accessor method. Increasing its visibility will improve your performance"

at line :

extern = 2;


I don't rely understand what they mean ?

They mean something like : the access to a private class field must be done always trough methods (logic until here), even if the field is access from a in
ner class - if this method is not existing maybe this method is generated (like the default constructor). If the field scope is relaxed (to default or prot
ected) then I don't need this "generated" method. Also I can only use the fields access methods.

If I am right, this is not performance issue ?


Regards,
Mihai

[ February 06, 2006: Message edited by: Mihai Radulescu ]

[Andrew: Changed subject line]
[ February 06, 2006: Message edited by: Andrew Monkhouse ]
 
Bridget Kennedy
Ranch Hand
Posts: 86
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Interesting blog on this very topic that thoroughly addresses your question.
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Posts: 12141
255
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Mihai,

I have moved this to the Performance forum. You can now find it here.

Regards, Andrew
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Posts: 12141
255
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Mihai,

Interesting issue. The blog Bridget points to describes the problem, but doesnt really go into why there might be a performance issue with it.

Basically ever time you call a method, space must be allocated on the stack for the method, and this is removed when you leave the method. So in theory you are going to get a performance hit from calling an accessor method.

But...

Good encapsulation means that we don't want to change the visibility of the variable. And since you are working on the SCJD project which is going to be marked, I think good practice should take precedence over the potential performance gain.

It is quite possible that the Java compiler could inline accessor methods anyway - so there might not be a real difference in performance (this would be java compiler dependant: no absolute statements can be made).

And I dont think you should ever chase after these "potential" performance gains when doing initial development. Wait until after your project is working (or the unit is working), and test it's performance then. If there is a problem with performance, then use a profiler to determine where the real problem exists and fix that. There is no point (IMHO) shaving a millisecond off access to this variable if it only gets called once in the entire application lifecycle.

Regards, Andrew
 
Mihai Radulescu
Ranch Hand
Posts: 918
IntelliJ IDE Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

Thanks Bridget for the blogs. Very interesting.

Thanks Andrew, I agree with you, I don't want to increase the visibility of the private fields in my outer class, I'm going to live with any performance hit rather than break encapsulation.

More, in my specs I have something like :

A clear design, such as will be readily understood by junior programmers, will be preferred to a complex one, even if the complex one is a little more efficient.


Of curse I'll document my decision in my choice.txt.

Thanks once more.

Regards
Mihai.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Andrew Monkhouse:

It is quite possible that the Java compiler could inline accessor methods anyway - so there might not be a real difference in performance (this would be java compiler dependant: no absolute statements can be made).


Actually it's the HotSpot Engine which might do this, so it will depend on the JVM used to run the code, and how it is configured.
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Posts: 12141
255
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Ilja.

Best regards, Andrew
 
Mihai Radulescu
Ranch Hand
Posts: 918
IntelliJ IDE Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi, Guys

Now I got some time to read and think about this synthetic accessors.
Now because I know about it I got on a bigger dilemma.
If I keep my variable scope private I keep my encapsulation, but if I use it in
a inner class I lose it(because the compiler generates this packed visible acces
s methods). In other words my code is syntactic correct (also the design, I thin
k) but the compiler does/change it. There are some workarounds but this makes my
code more complex.

I think that for the SCJD the first goal is to have a clear design (encapsulated
against security) so I don't suppose to care to much about it(as long I documen
t it, of course).

I am right ?


Regards, Mihai
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Posts: 12141
255
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Mihai,

I agree: for the SCJD project, keep your code clean.

As for projects external to the SCJD: While the compiler may be generating accessor methods, they are only discoverable via reflection (I think). So I do not think that these will cause too many problems. If you were concerned about potential security problems then you could work around it, but most users will just use the documented APIs.

Regards, Andrew
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Andrew Monkhouse:
As for projects external to the SCJD: While the compiler may be generating accessor methods, they are only discoverable via reflection (I think). So I do not think that these will cause too many problems. If you were concerned about potential security problems then you could work around it, but most users will just use the documented APIs.


And I you use the standard security settings, you can even access private fields using reflection, anyway.
 
Mihai Radulescu
Ranch Hand
Posts: 918
IntelliJ IDE Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Ilja,

What you mean by :

standard security settings

the SecurityManager features ?

Regards, Mihai.
[ February 13, 2006: Message edited by: Mihai Radulescu ]
 
Greg Bishop
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well hold on a minute. Wouldn't you achieve the same thing by marking the class as final protected instead of private? Then it can't be extended and it can't be accessed. No, not really. The children of the final protected class could still instantiate one. So to me this warning is asking you to change the composition of your code, which may not be what you want.
 
Nitesh Kant
Bartender
Posts: 1638
IntelliJ IDE Java MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Please DontWakeTheZombies
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!