Sanket Meghani

Greenhorn
+ Follow
since Jan 15, 2007
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Sanket Meghani

Thanks everyone for your inputs.

Ulf,

Yes, you are right. We should not make micro-optimizations. I posted this question just to get an insight if there is any significant performance difference between this two methods.

Thank you,
Sanket
13 years ago
Hi,

If I want to check if a map has a particular key or not. I could think of following two ways to do so.

1. Map.containsKey(KEY)

2. value = Map.get(KEY) and then check if value == null.

I think using Map.containsKey() would be faster. But I am not sure of the reason for that. Anybody could throw some light on this?

Thank you,
Sanket
13 years ago

I recently came to know that in Java ( and .Net as well ) we can access private members of a class using reflection. This link gives an example code Accessing_Private_Features_with_Reflection.

I think this will break the concept of encapsulation. However there might be some deep thinking involved before providing this feature. I am trying to think of reasons why would anybody (in this case Sun) would provide such feature or what would be the scenarios where in I would use this feature?

One of the possible usage I could think of is to test (unit test) private methods of a class. I can use this feature to write Junits for the private methods.

What would be the objective behind providing this feature or what would be other usages of this feature?

Thank you,
Sanket
14 years ago

The same piece of code works if I change source directory and destination directory to partially same path. For example the program works for srcFile = /data/logs/log.txt and destinationFile=/data/archive/log.txt. The problem occurs only if the destination directory do not have any overlapping path with source directory. For example program does not work for srcFile=/data/logs/log.txt and destinationFile=/export/home/log.txt
14 years ago
Hi,

I am trying to move a file from one directory to other directory. Source and destination directories are completely different. For example source dir = /data/logs and destination directory=/export/home/archived. While trying to move file from source directory to destination directory using File.renameTo(), it always fails. The same code is working on Windows machine.

Source code I am using is:



Here success is always false. I am executing this code on Solaris 9 and Java 1.5.0_16. This code runs successfully (success is true) on Windows machine.

Any thoughts on the reason for this behavior?

Thank you,
Sanket
14 years ago
You are correct. Only answer C is suffecient.

i.e inserting x5 = null will remove last reference to obj2.

Simliarly, if we insert x5 = x4 (i.e option E), it will also remove last reference to obj2 and hence making obj2 eligible for garbage collection.

So here the question is "what two lines of code, inserted independently at line 18, will make an object eligible for
garbage collection?"

So it is asking for two options which can be used independant of each other to make an object eligible for garbage collection.

Answer is you can use either of oprion C or E.

HTH,
Sanket
Looks a bit tricky,

When we use == operator for references, it will check if both the references refer to same objects(not the value!!) or not. On the other hand when we use == with standard datatypes, then it will check if their values are same or not.

Boolean b1 = new Boolean(true);
Boolean b2 = new Boolean(true);
boolean b3 = true;
Boolean b4 = true;

1. b1 == b2 : Here b1 and b2 are refernces and they are refering to two different objects. Hence b1 == b2 is false

2. b1 == b3 : Here b1 is a reference and b2 is a boolean variable. So when we write b1 == b3, the boolean value of b1 gets unboxed (refer Autoboxing/Unboxing) and will be compared with value of b3. So this becomes actual value comparison rather than reference equalization. And as both unboxed value of b1 and value of b3 are true, b1 == b3 is true.

3. b3 == b4 : Same as 2 above. Here value of b4 gets unboxed.

4. b1 == b4 : Same as 1 above.

Hence, D : false, true, true, false is correct answer.

In summary, while operating with boolean in an operation, if one operand is refernce to Boolean and other is a standard boolean datatype, then the value of Boolean refernce gets Unboxed and then the operation is performed between two simple boolean data.

HTH!!

Regards,
Sanket
D is the correct answer.

Java do not have a concept of destructors as in C++. They provide an alternative solution to clean up our resources through finalize() method.

The finalize() method will be called when the garbage collection routine runs and object is garbage collected. As you know, there is no guarantee either when the GC will run or whether it will run at all or not.

So if the GC runs and chooses the object for garbage collection during execution of your programme, then finalize() method will be called and "Harpic" will be printed on standard output. If JVM chooses not to run GC during execution of your programme, then finalize() method will not be called at all and "Harpic" will never gets printed.

So it is not deterministic to say when "Harpic" will be printed or it may not be printed at all.


Regards,
Sanket
"if super class throws the checked excpetion, base class should also throw the exception"

I assume, you made a typo mistake here and what you wanted to say is "if super class throws the checked excpetion, then sub class should also throw the exception"

Yes, this is correct.

The overriden method in the subclass can only throw a subset of the checked exception classes(including their subclasses) thrown by the inherited method in the superclass. This means that an overriding method cannot allow more checked exceptions in its throws clause than the inherited method does.

Allowing more checked exceptions in the overriding method would create problems for clients who already deal with the exceptions specified in the inherited method. Such clients would be ill prepared if an object of the subclass (under the guise of polymorphism) threw a checked exception they were not prepared for.

I hope I have not confused you more#

To summarize, if the super class method throws any checked exception then coresponding sub class method can only throw following type of exceptions:
1. Do not throw any exception
2. Throws all exceptions which are thrown by super class method
3. Throws any exceptions which are sub type of any exceptions thrown by super class method
4. Any run time exception

In all these cases, the code to call this method must be enclosed by try/catch with catch block for all the checked exceptions thrown by super class method.

Just learned a new internet acronym! HTH

Regards,
Sanket
Well,

Which method to call is determined at run time based on object type rather than reference type.

And you must be aware that we can only call overrriden methods from sub class using reference of super class. This is quite logical because compiler do not know at compile time what object is being referenced by super class reference. So at compile time it assumes you are calling the method of super class using super class reference(irrespective of object type) and hence it gives compile time error.

Hope this helps.

Regards,
Sanket
Hello EveryOne,

I was just playing around the wrapper classes and observed some unexpected behaviour.

public class HelloWorld
{
public static void main( String args[] )
{
Integer i1 = 100;
Integer i2 = 100;

System.out.println( "i1 == i2 : " + ( i1 == i2 ) );
}
}

Output of the above code is unexpected with different values of i1 and i2.

For the current values ( i1 = 100 and i2 = 100 ) the output is : "i1 == i2 : true"

But for the following code,

public class HelloWorld
{
public static void main( String args[] )
{
Integer i1 = 1000;
Integer i2 = 1000;

System.out.println( "i1 == i2 : " + ( i1 == i2 ) );
}
}

the output is "i1 == i2 : false"

From different conbinations I have observed that in the above code for values of i1 and i2 between -128 to 127 ( range of byte ), i1 == i2 evaluates to true and for other values i1 == i2 evaluates to false.

What could be the reason behind this behaviour?

Thank You,
Sanket Meghani.
16 years ago
Hello EveryOne,

I was just playing around the wrapper classes and observed some unexpected behaviour.

public class HelloWorld
{
public static void main( String args[] )
{
Integer i1 = 100;
Integer i2 = 100;

System.out.println( "i1 == i2 : " + ( i1 == i2 ) );
}
}

Output of the above code is unexpected with different values of i1 and i2.

For the current values ( i1 = 100 and i2 = 100 ) the output is : "i1 == i2 : true"

But for the following code,

public class HelloWorld
{
public static void main( String args[] )
{
Integer i1 = 1000;
Integer i2 = 1000;

System.out.println( "i1 == i2 : " + ( i1 == i2 ) );
}
}

the output is "i1 == i2 : false"

From different conbinations I have observed that in the above code for values of i1 and i2 between -128 to 127 ( range of byte ), i1 == i2 evaluates to true and for other values i1 == i2 evaluates to false.

What could be the reason behind this behaviour?

Thank You,
Sanket Meghani.
16 years ago
Hello There,

This is indeed a very interesting discussion.

I still have some confusion about whether the size of primitive data type is uniform across JVMs or not? Because the discussion in this thread suggests that Java Specification only gives the range of values a variable of perticular data type can have. It does not say anything about the size of it.

But an article on Sun's site says that a byte is 8 bit signed number, short is 16 bit signed number .... and so on.

The link to the article is : http://java.sun.com/docs/books/tutorial/java/nutsandbolts/datatypes.html

Please throw some light to reduce the confusion.


Thank You.
Sanket Meghani.
16 years ago
Answer 3 is correct answer.

Answer 1 and 2 are wrong because an object will be eligible for garbage collection in both conditions, they may or may not be garbage collected during program execution.

Answer 4 is wrong because GC does not guarantee that the program will never run out of memory, it just marks unreferenced memory to be elligible for garbage collection. They will be collected back by system when GC runs next time.