Himanshu Mall

+ Follow
since Jun 28, 2010
Noida, India
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Himanshu Mall

If not, please fix it so that it will.

Check your classpath option.

1) As a rule never forget "." (Current directory) in your classpath.
2) To run a java class within a package, provide fully qualified class name.

Play with -classpath option for a while. It will work.

Okk, thanks...

I missed it because its never mentioned explicitly in the books that i read (including Core Java, Sun Edition). Glad that now i know this.
So now we can say that:

" A sub class inherits the protected members of its Super Class and members with default level access (package level), if and only if both Sub Class and Super Class are in the same package".

Let me know if i missed something.
Dear Ganesan,

AFAIK Inherited Members in a subclass ( Protected access modifier) and whether you can access a member (using reference ) are two different things.

My question is that why a sub class inherits a default access level member from its super class, if both are in the same package ( Since package or default access level has nothing to do with Parent Child relationship, Why this subtle behavior).

Note: Access level is fine, since both are in same package, sub class or any other class in the same package can access the default access member (of parent or any other class ) through its reference.

Please correct me if i am wrong.

Thank you
Himanshu Mall

Can someone please help and tell me the reason why this is allowed?

A default access member(package level access) of SuperClass is inherited by the sub class, if both are in the same package.

Hello everyone,

I was going through the Ehcache user guide and got confused with one given example:

If DAO layer is handling the cache read and write activity itself, then is it a cache-aside pattern or cache-as-sor pattern?

As per my understanding it should be cache-as-sor, since for any Application, DAO is the s-o-r (system of record).

Did i miss something important?

Please help me out.


Start thinking in terms of "type" instead of "class and interface" and you ll see that all your confusion will just vanish.

P.S Both interface and class are TYPES.
Use parentheses appropriately.


Make the above mentioned change and run it.

Yes, you should not conclude anything about GC and you MUST NOT SPECULATE about it either.

Ref java.lang.Runtime.

Calling the gc method suggests that the Java Virtual Machine expend effort toward recycling unused objects in order to make the memory they currently occupy available for quick reuse. When control returns from the method call, the Java Virtual Machine has made a best effort to reclaim space from all discarded objects.

Moreover to make sure that GC ran is to see whether GC ran or not.

use -verbosegc flag while running the program.

java -verbosegc <Main-Class>

Let us know what you see when you do it.
I didnt get it. What is your point?

Pardon me if i am drifting away from Exam's objective.

But as soon as we start speaking class instead of type, we get hooked to that particular class. For loose coupling in pure sense, two objects should talk to each other over an abstraction, i.e. interface.

Please correct me if i am wrong.

The first one..


LSP: "Any method that uses references to the Base Class (Super Class) must be able to use objects of derived classes without knowing it"

Now lets think about it for a while.

You know everyone uses this day in and day out. You have a method that accepts an argument of Interface type, then at run time you hook up your object of actual class that implements the interface OR it accepts an argument of SuperClass type, and then you pass in the object of the derived type and all.

Lets take an example:

Now what is the first principle the above example breaks?

It is called Open-Closed Principle. i.e. doSomething method is not closed.

Open-Closed Principle: Code should be closed for modification, yet open for extension.

doSomething() should work with any object of type SuperClass or any derived type without even knowing about it.
But in the example above, Whenever a new subtype comes in the inheritance tree, one has to modify the existing code(doSomething method) and use ifs and elses and elseifs and nested if else elsifs.

Well you just violated LSP principle here. That is all LSP says.

Read: LSP

Hope it helps.