Anchit Herredia

Raju Champaklal wrote:this code compiles.....but the code below this doesnt....why? and whats same erasure?
import java.util.*; class Test { void say(Set<Double> set) { } void say(SortedSet<Double> set) { } }

import java.util.*; class Test { void say(Set<Double> set) { } void say(Set<Boolean> set) { } }

I noticed that we haven't replied to this one yet. So here's the answer to your question:
In Java 1.5, while fetching the objects from any collection it would be returned as an instance of "Object class" (which is the simply father of all classes). Now we have to typecast this returned object to whatever actual object it was. For example, if we got a string object we would say:

Iterator iteratorObject = HashSetObject.iterator(); String str = (String) iteratorObject.next();

But the problem with this was that if the object stored in the collection was not a String object we would get a runtime error. So in Java 1.6 we have the capability of generics. Here we tell the compiler before hand that our collection (HashSet in my example above) would be storing some particular type, such as string. So once the compiler knows that HashSet object stores only Strings it can point out any mistakes in the code where we are not storing String.

Coming back to your question, the generics checking happens during compile-time. So during compilation it is checked that you are only putting String objects into HashSetObject. However, after compilation the generic is removed. So if you have two methods with same name but different generics both will still have the exact same signature after compilation. But then there would be an error. We would two methods with exact same signature but different bodies. This cannot be allowed hence the compiler gives you that error.

Hope that answers. Here's some more info: Generics_in_Java

system.out.println is neither a variable nor a method definition. You are just calling an existing method. It is a statement. Not a definition. So you can put it in the body of a method but not outside it.

Prasad Kharkar wrote:@Anchit
it it true that we cannot instantiate abstract classes
but the abstract class constructor is called when a subclass of abstract class is instantiated
this is because constructor has implicit call to super constructor

Please tell me why that needs to happen?

Suppose class B is extending class A:

During instantiation of class B object I understand that constuctorB will implicitly call constructorA. This is because we are not only creating everything specified in class B but also other members such as private methods and private variables of class A also need to exist in the memory. For example: Class A has a public method display() that uses its private variables. We extend class A and call it class B and add a few more methods. Now we create an instance of class B. We know that we can invoke display() method on B object. How is this possible? It can only happen when everything defined in A is also present in the memory. Hence in B's constructor even if we don't call super() we know that implicitly that call will still occur.

Okay I just now realized that maybe the same principle applies to the case Class B implements abstract class A . One trivial clarification regarding this:

What happens in the following case:
abstract Class A
|
| (B extends A)
|
abstract Class B
|
| (C extends B)
|
abstract Class C
|
| (D implements C)
|
Class D <== we instantiate an object for D. Here is it true that constructor for D calls constructor for C which in turn calls its super all the way till A? I think that that is what should happen.

Devaka Cooray wrote:There are several chapter-wise mock tests listed in ScjpFaq

An excellent reference! I'm now on the javaprepare website where we have a lot of questions that are topic-wise and that too for free! hehe Thanks a load for this man.

Henry Wong wrote:
Anyway, to answer this question. Sure, it is perfectly valid to have a private constructor in an abstract class. I can think of a few ways that it can be invoked. For example, there is another constructor in the abstract class that calls this one. Or there is a static factory method that can be invoked -- that creates an anonymous inner class. Or there is actually a nested concrete class that inherits from the abstract class.

Henry

Why can we have constructors for abstract classes? Don't constructors allocate memory to an object at the time of instantiation? We know that abstract classes cannot be instantiated, isn't that true?

Hi,

I'm looking for additional questions to solve apart from the ones given in Kathy and Bert's book on SCJP 6. I already finished the questions at the end of the chapter and feel it would be very helpful if I could answer more questions focused on the same chapter. Is there any place where I can get more questions chapter-wise?

I'm not looking for the mock exam material. I only need more questions and chapterwise on their book. Any help would be appreciated.

Thanks,
Anchit

Henry Wong wrote:
If you really want to, I guess you can get the source code for the JVM from open source. Google for "openjdk".

Be warn though, the code is complex. And written mostly in C and C++.

Henry

But does that mean that any program written in Java will be slower than the same one written in C++?

(Can't believe Java was written using the shitty C++)

Prasad Kharkar wrote:Whenever we are calling println method
then all the stuff that we are printing in it is calculated or executed first

see the code for explanation...
...
Hope this helps
happy preparation

Superb answer, Prasad! Well done!

Seema Kekre wrote:

Anchit Herredia wrote:
In other words any class extending Uber will be able to use y as its own member. .

This is partially correct. Any class extending Uber in the same package can use its default members as its own, static or non-static.

Edit: Highlighting as its own to be clear

Thanks. I love this forum!

I would highly recommend SCJP preparation book by Kathy Sierra and Bert Bates. You are going to love it!

Let me explain it as simple as possible:

Now y is declared as:

static int y = 2;

This means default modifier for y. In other words any class extending Uber will be able to use y as its own member. That is why you can freely use y in Minor in the same way you can use it in Uber. Another thing is you can use Minor.y because y is a static variable. You don't need to even instantiate the Minor class like in line 11. Let me know if anything is not clear.

Joanne Neal wrote:

Anchit Herredia wrote:2) There has to be at least 1 public class in trial1.java. This is because each source file must contain at least 1 public class.

This is wrong. A source file does not need to contain a public class but if it does there can be only one.

Thanks for correcting me. Yes, there can be no public classes (in which case there will only be "default" classes and they can all have any names irrespective of the filename). The name restriction of class name matching the filename is only applicable to the public class (if present).

Rohit Varma wrote:Thanks Rene and Anchit.

I scored 90% marks.Ankit, I prepared for around 3 months and it was about 2-3 hours a day.
I gave ExamLab exam and K&B mock exams. Well, the scores were very depressing,but learn a lot from them.

Best of luck for your exam. By the way , this forum rocks

Excellent! I'll do the same.

Ok few things that might be wrong:

1) trial1.java needs to have T capital (obviously this isn't the cause of your problem but just something to remember)

2) There has to be at least 1 public class in trial1.java. This is because each source file must contain at least 1 public class. Currently, there appears to be no public class present. Also, the public class should be named trial1 in your case (as per the source file name).

3) Another thing which you might want to check is the package structure. Since you have got two packages and both are root then you should have two folders both inside your project workspace. For example, if your project name is "Test" then we should have the following structure for the source files:

Test (folder)
|
|-- kkk (folder)
|--trial.java
|
|-- skk (folder)
|-- MyClass.java

Too bad I don't have access to my pc right now or I would have checked your code manually. Let me know if this doesn't work.

Henry Wong wrote:
Keep in mind that inherited doesn't mean that the sub class gets a copy of the method, it calls the super's version of the method.

And in the Exam class -- the display() method is part of that class; compiled with the class; and from the point of that method, the "this" reference is of type Exam. And since polymorphism doesn't apply to instance variables, it will get the Exam version.

Henry

An excellent answer! This made the concept quite clear to me.

Now if what you say is true then it implies that if I overide the display() method in Scjp class and run the same program again then the output should be "Killing".
This is because:
-> calling display() will actually now call this.display()
-> since this.display() has been compiled with scjp class it will call this.difficultLevel
-> meaning that this.difficultyLevel should be printed.

I'll verify this once I reach home and have access to my pc. I'll post my findings in this thread. hehe