• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

String References and Performance

 
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello Friends,

In our project, we are aasigning values that are coming from database to String references as follows
String name = message[1];
String address = message[2]; .......................................upto 30 values;

and then we are using these String references to create an object of bean class using setter methods.

myBean.setName(name);
myBean.setAddress(address);

Bean object can be created using message[] also but perhaps, purpose of this is just to make the code readable.

IS it a good practice? Does this create memory issues because after creating bean object we are not using above String references?
 
Ranch Hand
Posts: 35
Hibernate jQuery Eclipse IDE
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If these strings are getting created once in while its ok but still Nobody will recommend you this implementation. If you want your code to be more readable and easy to understand please make use of comments like
myBean.setName(message[1]); // name
myBean.setAddress(message[2]); // address

This will help code to be easily maintained.
 
author & internet detective
Posts: 41860
908
Eclipse IDE VI Editor Java
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Neha,
Compared to the database access time, the String references are too tiny to worry about it. I do find the following to be easier to follow though. Especially if you have thirty things and the bean setter names are self explanatory. I wouldn't add the comments that Rupesh recommends though. It is obvious from the setter names what they are; the comment is redundant.

 
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Couple of things

If, after setting the values you were doing some expensive computations (in the same method) AND there are 100s or 1000s of threads executing the same code concurrently, then there could be memory issues. Otherwise I do not see any performance issues.

Just for ease of maintainability, I would do this.

int i=0;
String name = messages[i++];
String address = messages[i++];
..
..
..

Why?
Just imagine if you had to add a color attribute somewhere in the middle of your message array.

Again, in the interest of maintainability, I would provide a constructor to the MyBean class with a String[] parameter. This, so that the semantics of creation of this bean are present in a single location. I would not want the code for populating this bean to be spread throughout the application.

Just my 2 cents.

 
Ranch Hand
Posts: 88
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


String name = message[1]; -------------------------------------------------------------------------------------------- refer pt 1
String address = message[2]; .......................................upto 30 values;

and then we are using these String references to create an object of bean class using setter methods.

myBean.setName(name); --------------------------------------------------------------------------------------------- refer pt 2
myBean.setAddress(address);



Please note that @ Ref pt 1 as well as pt 2 you ARE NOT CERATING any String object; your are decaring REFERENCES (pointers) to String Obejct.

String Object is constructed ONLY IF WE USE NEW operator like new String("TEST"); else String INTERN pool is used....
I see NO problem what so ever unless in setXXX(String s) you are creating a String Object using NEW operator.


 
Ranch Hand
Posts: 384
Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

K Abhijit wrote:


String name = message[1]; -------------------------------------------------------------------------------------------- refer pt 1
String address = message[2]; .......................................upto 30 values;

and then we are using these String references to create an object of bean class using setter methods.

myBean.setName(name); --------------------------------------------------------------------------------------------- refer pt 2
myBean.setAddress(address);



Please note that @ Ref pt 1 as well as pt 2 you ARE NOT CERATING any String object; your are decaring REFERENCES (pointers) to String Obejct.

String Object is constructed ONLY IF WE USE NEW operator like new String("TEST"); else String INTERN pool is used....
I see NO problem what so ever unless in setXXX(String s) you are creating a String Object using NEW operator.




It is not so that String Objects are created only if you use new with the String Constructor ... literal value assignments may also create new String Objects

and yes if messages[1] is not already in String Pool a new String Object will be created
 
K Abhijit
Ranch Hand
Posts: 88
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Actually that's what I meant....may be there was a room for improvement in a stating it; So let me re-iterate

When we DON'T use new operator then INTERN pool is referred and if that LITERAL not found in pool, Object is constructed...

in this case particularly , it would NEVER be the case since all Objects have already been constructed.....

anyway thanks for correction
 
Lalit Mehra
Ranch Hand
Posts: 384
Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
your welcome buddy ...
 
Rancher
Posts: 4803
7
Mac OS X VI Editor Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Rupesh Mhatre wrote:If these strings are getting created once in while its ok but still Nobody will recommend you this implementation. If you want your code to be more readable and easy to understand please make use of comments like
myBean.setName(message[1]); // name
myBean.setAddress(message[2]); // address

This will help code to be easily maintained.



I disagree here. The setter's name, setName() is all you should need to know that you are setting the name. the comment of
// name

is redundant and error prone. If your setter names are not clear, fix them. The problem is likely to come up in the middle of a long set of setter calls


myBean.setBirthDate(message[12]); // gender

Here, you have changed which setter you are calling and did not change the comment.


Back on topic for Performance, this seems like a classic premature optimization. The JIT will make all of these the same.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic