Innar Made

+ Follow
since May 12, 2009
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 Innar Made

Yes, the arithmetic operators result in an int if the operands are int or smaller i.e.

int + int = int
byte + byte = int
short + byte = int
int + long = long
short + long = long

Except when the operands are compile time constants and fit into the result, like so:
Hi all,

About your variable assignment question:

Java Language Specification explains that you can narrow int to byte, short or char if the int value is constant and in valid range of the target type:

A narrowing primitive conversion may be used if the type of the variable is byte, short, or char, and the value of the constant expression is representable in the type of the variable.
A narrowing primitive conversion followed by a boxing conversion may be used if the type of the variable is :
Byte and the value of the constant expression is representable in the type byte.
Short and the value of the constant expression is representable in the type short.
Character and the value of the constant expression is representable in the type char.

It's good question, why we cannot widen int to Long, or int to Double? Primitive widening from int to long or int to double is legal.

Seems like the compiler boxes the int value to Integer first? Then of cource you cannot widen Integer to Long or Double, cause IS-A fails. The question is why the compiler doesn't do primitive widening first and then box?

And your question about methods:

Passing values to methods is not same as assigning values to variables (i.e Short s = 10;). The method wrap_byte(Byte b) just don't know what to do with an int or Integer. Narrowing doesn't apply here like it applied to assigning values to variables. For this to work you need to explicitly cast int to byte. Now autoboxing can work.

So for this to work you need:

Notice however that this is legal (because int can be widened to long)

I hope this helps. I'm sure somebody can explain more clear and easier than me
Hey Anuradha,

Synchronized blocks are better to use than synchronized methods. The reason give there is method level synchronization affects performance?

This depends of the kind of code you run.

If your method has code that don't need to be synchronized, then it would make sense to use synchronized block as it gives finer grained control over what you synchronize. Let's say the same method that has lot's of code that don't need to be synchronized and you synchronize on method level, then it means that all the other threads will have to wait till currently executing thread finishes the method. On the other hand, if you synchronize only what is really needed using the synchronized block, then other threads can run the code before the synchronized block without needing to wait after other threads.

Note that there should be no performance differences between synchronized method and a synchronized block if the method contains only code that must be synchronized. For example these two methods should be equivalent in regards to performance and concurrency (similar ex in K&B on page 737):
Hey Anuradha,

Yes, you are correct.

No other thread can't get into the synchronized block while some thread owns the sync object's lock. When the synchronized block finishes then sync object lock is released and other threads can start to compete to get it. Whoever gets it can then enter the synchronized block.
Hey guys,

I am using JDK with Eclipse Galileo. You are right, Ankit, compiling from command line it all works! I guess the problem is solved then
Hey again, Ankit : )

Can you elaborate more about your statement?

2. It doesn't matter whether InnerClass extends OuterClass or not, you can't create an anonymous inner class of a non-static inner class...

Here I am making an anonymous inner class from a non-static inner class, it compiles and prints out "Greetings from inner class"

Thanks for your patience.
Hey Ankit,

Thanks for your reply. Just to confirm that I understood you correctly:
1. anonymous inner classes cannot define new constructors;
2. if inner class InnerClass extends outer class OuterClass then subclassing InnerClass by making an anonymous inner class fails because it cannot call the parent constructor of InnerClass as InnerClass doesn't have instance of OuterClass.
Hello ranchers,

I just finished K&B chapter on inner classes. I was happily experimenting around by writing small test programs till I got stuck with this one.

I don't understand why making InnerClass() {}; causes compile time error. The error message says something like "No enclosing instance of type OuterClass is available due to some intermediate constructor invocation". Can anyone please explain me this? Thanks
Hi all,

From Java6 Writer javadoc about close() method:

Closes the stream, flushing it first. Once the stream has been closed, further write() or flush() invocations will cause an IOException to be thrown. Closing a previously closed stream has no effect.

The flush() method ensures stream flushing.

Practice shows that usually stuff gets written to file with just close() method. But it's always recommended and encouraged to call flush before closing the stream!
Since the read() method already reads a single character from the stream, then calling readLine() after that continues reading from the stream where it left off last time. Or in other words, lets imagine that the stream position is 0 before the read() method. Now the read() method executes by reading a single character and stream position is now 1. So calling the readLine() starts reading at the second character.

Check the code below:

The output is:

read() reads character 84
readLine() result is: his is first line

84 in ASCII table is 'T'
Thanks, Vijitha and Henry, for correcting me! Now I understand it. Gonna continue with next chapter of K&B book
Thanks, Abimaran and Vijitha! I think I get it now.

Since && and || have higher precedence, they will be evaluated first.

Just my reflection of how I understand this now:

Here short-circuit && sees that b is false and fails the if expression. The boolean b inside the IF doesn't get assigned to true, since IF condition was failed by && already.

Here the short-circuit || sees that b is true and the IF condition succeeds right after that, b doesn't get assigned to true.

Thanks again
Hey, Abimaran Kugathasan!

Do you mean that && has higher precedence than b = true? Interesting thought. That would also comply why the if expression on line 26 evaluates to true (since it has parenthesis around b = true and thereby making it higher precedence than &&). But in that case what about the if condition on line 20, with the OR. If || has higher precedence than b = true, then both sides should be false also?

I would like some guidance how to think about assigning values in an if statement. Please see the code below:

The output is:

b = true
FAILED: b = true && b
b = true || b
(b = true) && b

Now, what confuses me is line 12, why it evaluates to false?

Here is how I have understood how assigning inside an if should work. Let's look at line 6 for a moment. At first, b is false. Inside the if expression b is assigned the value true. After assignment IF condition checks b value and it evaluates to true.

If I think like that then in my mind line 12 should have succeeded also. Boolean b is initially false. When code reaches to if statement, then firstly b is set to true (like in line 6). After the assignment the left hand side of && evaluates to true and right hand side also. Condition should succeed, but it doesn't. What is ill in my logic?

Hello Rafi,

It will not compile. The compiler slaps us in the face with message something like "Type mismatch: cannot convert from List<Dog> to List<Animal>"

This however compiles and works fine:

Now we declared that this method will return a List of Animals, but now it may also contain Animal subclasses like Dog.