• 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

Adding more classes via import statements

 
Ranch Hand
Posts: 18944
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have Certain Doubts about the questions in this exam marcus green
Java Programmer Certification Mock Exam No 2 Last Updated 29 February 2000Question 57
Which of the following statements are true?
1) Adding more classes via import statements will cause a performance overhead, only import classes you actually use.
2) Under no circumstances can a class be defined with the private modifier
3) A inner class may under some circumstances be defined with the protected modifier
4) An interface cannot be instantiated
Given Answer is 3, 4
I feel that 1,3,4 should be the answer
I feel Option 1 also should be the answer as all, the static methods & variable of the classes included through import statements will be loaded in the memory by the JVM when the Class is loaded ( thus will be memory Hogs with no use ) . please correct if I am wrong
 
Rancher
Posts: 241
Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Your explanation seems right to me, maybe it has more to do with the second part of the statement "only import classes you actually use". No one would set up import statements for only the specific classes they need, probably because they don't know exactly which ones, or because it would result in a lot of verbage, or something like that.
Still, if it's a true/false situation, and the first part is true but the second is false.....???
Eric
 
Ranch Hand
Posts: 64
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Import statements can be as numerous without a performance cost. It is only at compile time that you will feel the weight of the various imports. Becoz only the classes that you actually use are compiled with your program not the entire package. So the qs of loading classes that hog memory and are useless doesnt arise. Import statements only affect cimpile time, not performance
 
Anonymous
Ranch Hand
Posts: 18944
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Nalini
you dont get my point i am talking about those classes which have static Methods & static Variables & static Code Blocks , these would be unnecessary memory hogs at run time, because whether you instantiate those classes or not these will be automatically loaded by the JVM when the class is loaded
 
Sheriff
Posts: 5782
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Good morning guys.
Very Interesting discussion.
My guess is JLS only outlines the exact policies to be incorporated during the class loading process. If you look at JLS section 12.2 Loading of Classes and Interfaces, the tone of the paragraph(s) suggest only the expected behaviour, but not the implementation details. This means the class loading procedure and scope for improvements to reduce the performance overhead is JVM implementation specific. Just like Garbage Collection specs.
The same section also talks about "linkage". The class loading means building the symbol table. IMO, this process is costs the same whether the method is static or not. The symbol table(a.k.a. table of linkage references ) also serves as a cache. Subsequent references are retrieved and operated upon using the cache table to improve performance.
Well, this is what I was able to read and digest( its' monday morning, don't expect 100% assimilation ). Let me hear from you folks if you think otherwise.

Ajith
reply
    Bookmark Topic Watch Topic
  • New Topic