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.

A good read about Object Initialization.

Object Initialization in Java

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

Hi,

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.

package certification; public class Parent { int x = 9; // default access } package certification; public class Child extends Parent { public void test1() { System.out.println("Inherited member x is : "+x); // no problem } }

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.

@sumit

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.

q=(byte)(a+b);



Make the above mentioned change and run it.

@Prateek

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?

@Abhimaran

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..

/** * */ package com.toy.programs; /** * @author hmall * */ public class OpDemo { /** * @param args */ public static void main(String[] args) { boolean a = true; boolean b = false; String str; str = b || a ? "first":"second"; System.out.println(str); } } Answer: first [url=http://pages.cs.wisc.edu/~willb/cs302/spring-07/java-operator-precedence.pdf]Good Reference[/url]

@Anand

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:

/** * */ package com.scjp; class SuperClass { public void myMethod() { System.out.println("myMethod of the SuperClass called"); } } class SubClass extends SuperClass { public void subMethod() { System.out.println("subMethod of the SubClass called"); } } /** * @author hmall * */ public class LSPViolationDemo { public static void main(String[] args) { SuperClass object1 = new SuperClass(); // create an object of superclass. SubClass object2 = new SubClass(); // create an object of subclass.Check the reference Type. doSomething(object1); doSomething(object2); } private static void doSomething(SuperClass object) { if(object.getClass() == SuperClass.class) { // If actual object is of type SuperClass, call myMethod. System.out.println("Whoa I got the actual superclass object so lets call myMethod"); object.myMethod(); }else { // If actual object is of type SubClass, then invoke subMethod and yes i know i can downcast it to SubClass and call subMethod. System.out.println("Just recieved an actual subclass object so lets call subMethod"); ((SubClass)object).subMethod(); } } }

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.