Neelesh Bodas

Ranch Hand
+ Follow
since Jul 20, 2006
Merit badge: grant badges
For More
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 Neelesh Bodas

Originally posted by enen:
What are runtime exceptions as far as JVM and programmtic exceptions mentioned above is concerned?

Limiting ourselves only to the 10 Throwables listed above, all the exceptions in the above list are RuntimeExceptions. Note that the list has 4 errors and 6 exceptions.

Also note that all the 10 Throwables in the above list can be thrown fromanywhere without declaring or handling them.
> Test test = new Test();

A new Test object is created on the heap. There is one reference that refers to this object. The reference itself is on stack.

> Test.Inner inner = Inner();

A new Inner object is created on the heap. The reference variable "inner" lies on stack and refers to the Inner instance on the heap. The inner object has a reference to the Test object. Thus, note that the heap-based instance of Test has now two references referring to it - one on stack and other from within the instance of Inner.

Also note that the instance of the Test class doesNOT have a reference to the instance of the Inner class.

> test = null;

The stack reference no more refers to anything. Thus, the heap-based instance of Test has only one reference referring to it - the reference through the instance of Inner.

> System.gc();

Neither Inner nor Test instance is eligible for GC - each of them has a reference referring to it.

> inner.print();

Invokes print method on the instance of Inner referenced by the stack-based reference "inner".

As an aside, note that calling a garbage-collector on invoking System.gc() is not guaranteed.
pre and post increment operators have same precedence.

Assuming i has value 0 before the following expression is reached :
int j = ++i + i + i++ + i + i++;

Since + is left associative, the above expression is same as :

int j = ((((++i + i) + i++) + i) + i++)

Also, the LHS operand of + will be evaluated completely before the RHS operand is evaluated. So, when you do (++i + i), if i is 0 initially, then this expression evaluates to (1+1). Similarly, (i++ + i) will evaluate to (0+1).
You can't.

Note that the only way to access an "anonymous inner class" is through the reference of the super class (Popcorn in the current case.) Since Popcorn class doesnot know "sizzle" method, there is no way you can call sizzle method on the anonymous inner class just created.
Quoting from the Online reference,

The equals method for class Object implements the most discriminating possible equivalence relation on objects; that is, for any non-null reference values x and y, this method returns true if and only if x and y refer to the same object (x == y has the value true).

As far as the exact "implementation" of equals() method is concerned,I am not sure whether Object class is implemented in java or in a native language like C.
The handle-or-declare rule (in context of a method M) applys to the checked exceptions that are thrown in the method M , or that are declared by the methods called inside M.

In the first case, the doThat() method throws and handles the exception. Since the checked exception that might be thrown is handled, the handle-or-declare rule is seen in action here. Now, for doThis() method, no checked exception gets thrown in the method. Also, none of the methods that doThis() calls declares any of the checked exception. Hence doThis() method neither needs to declare any exception, nor needs to catch any exception. (Note that the exception that might be thrown in doThat() method is never escaped from doThat() method and hence doThis() method is not even aware of this exception. )

In the second case, you are explicitly declaring that exception of class Exception (or its any subclass) might escape doThat() method. In this case, doThis() method needs to either handle or declare this exception according to the rule stated above.

Originally posted by Carlos Gomez:
Because the Integer class override the equals method and certain primitives are always to be boxed into the same immutable wrapper objects. These special values are:

The boolean values true and false
The byte values
The char values in the range '\u0000' to '\u007F'
The short and int values between -128 and 127

for instance:

Integer j1 = 148;
Integer j2 = 148;
System.out.println(j1 == j2); // FALSE

Integer k1 = 126;
Integer k2 = 126;
System.out.println(k == k); // TRUE

Carlos' reply is almost irelevant to the question - for two reasons:

a) Note that

Integer i = 24;

is NOT same as

Integer i = new Integer(24);

Whatever Carlos has pointed out (special cases etc) holds for the former case, not in the later case.

b) Carlos talks about "==", which is different than what Xiao is talking about - the equals() method.

Coming back to the question posted by Xiao, The class Integer overrides "equals" method so that any two integers with the same numeric value are considered "equal". As a result, see that

Integer i = new Integer(344);
Integer j = new Integer(344);
System.out.println(i.equals(j)); //true.

On the other hand, the class Value doesnot override the equals() method. The equals() method, as defined in the "Object" class returns the same result as "==". Since two different value instances are never "==", hence the equals() method will return false.
Thanks all for the reply.
17 years ago

I wanted to know what was the reason of not providing "delete" functionality in Java? I agree that Java wanted the programmer to be free from all the memory-related dirty work, but it was possible to do both : provide "delete" as well as have an in-built GC. The typical requirement as I see could be in a real-time-application : where I DONOT want the garbage collector to run during a specific period. I would rather prefer to free the ununsed memory myself at some non-critical stage in the code. The "delete" functionality could be useful under such circumstances.
17 years ago
for SCJP 1.5, you can atleast take the three mock exams : The two master exams and Whizlib diagnostic tests. Also try various mock exams from the list . Try markus green exams. (Skip the questions related to swing, Byte related IO and bit operations)

I found the exam somewhat easier than the master exams. But be prepared to face some tough questions.

If you have highlighted important topics in K&B then it will be easier for you to read them now. Otherwise, you can still read-thorugh the book again and highlight important points to refer later.

There will be questions from almost all exam objectives. As far as number of questions is concerned, I am not aware about what weightage is given to what topic. But the questions that I got had a mix of all topics. I don't remember any topic being left out.

You can go through some tips given here. Also do check the advices given by Other ranchers in the Results Forum. I read them and found them quite useful.
[ August 23, 2006: Message edited by: Neelesh Bodas ]

Originally posted by Vaibhav Chauhan:
Thanks Jasiek and Neelesh ....I agree with you but tell me that if subclass overridding method throw a wider exception (say Exception) whereas the superclass overridden method throw NullPointerException, then compiler should be glad because anyway we are handling NullPointerException (and ofcourse some more exceptions) through "Exception" in subclass overridding method. It ensures that anyhow we are taking care of NullPointerException.

We are not handling, we are throwing. Remember that this rule talks about the exceptions that are thrown - and by "thrown", we mean exceptions that escape the method.

The overridden method can handle any checked and unchecked exceptions with a try-catch block. The rule that you quoted does not apply to exceptions that are "handled" using a try-catch block.
Because when you override a method, you must preserve the contract made by the overridden method. In other words, you should not break promises given by the overridden method.

The Superclass.go() method promises the user of the method that it will NOT throw any checked exceptions except the FNFE. Now suppose you override this method and violate the exception specification :

And then, suppose a user does this :

Now, as far as user is concerned, the go() method of var should not throw anything other than FNFE. (Note that var's static type is Superclass). He will write the code that uses var.go() accordingly. However, this would break the declare-or-handle rule for the checked exceptions : The exception that go() is actually throwing is neither declared nor handled by the user.

Hence, in order to avoid surprises, it makes sense that the overridding method doesnot throw any broader checked exceptions than the ones declared by the overridden method.
I recently gave the exam but I didnot find any "demo" there. (May be I missed that link, I am not sure). Before you start the exam, they will ask you a set of 7-8 Survey questions (asking about your proficiency in various java concepts.) The time taken by you in answering these questions is not included in the total exam time. However, after the exam starts (and the clock starts), the first three pages ask you to sign some non-disclosure agreements etc. The time required by you to accept these is included in the exam time.
because myName is a static member of the class. The fact that java allows you to reference a static member using the instance of the class is simply a syntactic sugar, it doesnot use the instance reference to retrive the value of the member
[ August 23, 2006: Message edited by: Neelesh Bodas ]