I generally define interfaces for everything, and then when appropriate provide abstract implementations of those interfaces. This gives the choice to concrete classes to extend from an abstract class or completely re-implement the interface/contract. Either way, calling code only needs to depend on the interface, which is something that can be defined very early on and is not tied to a specific implementation. [ April 27, 2007: Message edited by: Andy Morris ]
Well what I was thinking that you were saying was that interfaces are visible by all classes (except when nested like you said), but you can obviously give an interface default access, in which case only classes inside that package can implement it, or even see it. That's useful for developing low level components in a de-coupled fashion.
That might achieve what Sanjeev was really tring to do (not quite the same), though one of the main purposes of interfaces is not to restrict implementation to a single class - I think that's worth understanding!
In anycase, this is not really anything to do with SCJP...
Nothing is eligible for gc in that situation - you never created any objects!
'objectName' is just a reference variable, which can can contain the memory address of an object of type 'SomeClassName', but it is nothing more than that. Since you assigned it the value 'null', it doesn't refer to any object.
Reference variable 'c3' never refers to an object, so there is no concept of an object it refers to being eligible for garbage collection.
'c1' has an attribute 'story' of type Short, so when reference variable c1 is set to null, both the Cardboard AND Short objects become eligible for gc. [ March 21, 2007: Message edited by: Andy Morris ]
So when you say it compiles successfully you're saying it produces a .class file?
I'd be very suprised if it did. The runtime exception you're getting isn't because it's running an 'empty' class file, it's because the class file doesn't exist.
I doubt anyone here can tell you why the designers of Java decided not to warn you (or abort compilation) if it finds an empty .java file. My only thoughts are that an empty java file has no negative impact, so why bother failing compilation over it? I'd have thought a compiler warning would be useful though.
When adding/retrieving from collections that use hashing to allocate storage it's quite possible to get 'collisions', making it slow to allocate and retrieve. If you waited till it was completely full before expanding it's very likely you'd have had many, many collisions - so to avoid this they do it early.
But not too early as you might end up wasting memory, and there could be other reasons (maybe getting all the values in a list would take time when 90% of the spaces are empty).
ArrayLists don't use hashing, and so waiting for the current allocation to fill up doesn't cost anything. [ March 15, 2007: Message edited by: Andy Morris ]
You have a lower case s in the dog's doStuff() method, so it never gets invoked!
If it was coded correctly the second line would have printed 'd:a:if instance of dog', because when you casted the animal that is a dog, to a dog, you would have invoked the dog's doStuff() method (not the animal's one!).
Originally posted by Guru dhaasan: But the variables are coderanch, final and static
As you should know variables that are final and static are constants, and being able to define them in interfaces makes it useful so that all implementing classes can use them. [ March 15, 2007: Message edited by: Andy Morris ]
