S.R Paul

Ranch Hand
+ Follow
since Mar 22, 2012
S.R likes ...
Eclipse IDE C++ Java
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
1
Received in last 30 days
0
Total given
1
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by S.R Paul

Campbell Ritchie wrote:I think it is unfortunate that the same word “cast” is used for both.


Ya, that's the reason for my misconception. Anyway now cleared.
Thank you guys
11 years ago
Thanks Jesper

"I have some object here, and I want you to treat it as if it of type X"


So, Casting is a methodology to say to change the way/type how the object should be treated and not as a object conversion technique. (except Primitives, they are really widened /broadened)
Is that correct?
11 years ago
Hi, Ranchers!
Check the code below

BUT,
* why do the code prints 'Barking' instead of 'Generic animal sound'?
* Is that casting not considered(or rejected silently) by the JVM?
* Is casting for Ref types / object types?

I couldn't accept the output as it is without any explanation.
11 years ago
@Luke

But does the inclusive parameter add so much to the method signature as to require a type difference in the return? Why not just make the return type a SortedSet as well?


Ya, I thought so. Does inclusive of an element cause/need a return type change? Weird!!!

@Winston

As I recall, most Sets are simply a container to a Map<K, Boolean>


Getting interesting. Need more reading.

Anyway, thank you all for all the replies.
11 years ago
Thank you Rob spoor and Winston

@Rob Spoor

In this case it would actually work, but that's because TreeSet is itself only a wrapper for a NavigableMap (by default a TreeMap)


Could you make it clear (or provide ref's)
How could a Set can be a Wrapper to a Map?
How could Map<K,V> can be converted into a Set<e>? (you know Key, Value and Element)

@Winston

indeed, if you don't need to use it after that, you can simply make the last line:

Set<Integer> smallSet = times.headSet(100);


Seems better, more broader type ref, less headache
11 years ago
Thanks to Steve.

time.headSet() method returns a SortedSet<Integer>, not a TreeSet<Integer>


I should have check this before posting.

not all SortedSet<Integer>s are TreeSet<Integer>s


also helped to be clear

Thank you
11 years ago
Hi ranchers!
My question is about use casting in a TreeSet. Check the code below

It gives compiler warning about unchecked conversion.

warning: [unchecked] unchecked conversion
found : java.util.TreeSet
required: java.util.TreeSet<java.lang.Integer>
TreeSet<Integer> set = (TreeSet)times.headSet(100);


My questions are,
1. We declared both TreeSets as Integer type, then why do we need to cast again? (both are same in Collection and Type)
2. If so, then what is the specialty of using generics over non-generics here? (except the type safeness)
I feel redundancy over here, what do you think?
11 years ago

thank you paul it helped a lot.


That's fine, but next time more clear code.
Anyway, Welcome to the Ranch.
11 years ago
It is the "Enhanced for loop".
It makes the looping easier for the collections and Arrays.

Here how it works;

for(shoppingCartItem scItem:items)...


ShoppingCartItem is a user defined class.
scItem is the reference of the object, which will be assigned while looping (the object will be retrieve from the collection "item")
items is the reference of the object, which is a Collection and type of ShoppingCartItem (mostly)

You can read the segment like this,
"for each object (ShoppingCartItem type)in the collection item, retrieve it and assign it to the scItem reference and do some work inside the loop body"

I hope it helps.
11 years ago
It depends on your knowledge Level (concerning Java).
If you are not a total beginner for Java, then K&B is well enough. (OR other languages like C#)
If not, then taking a course will make things easier.
Hi Ravi,
I don't know the hardness of the NIIT exam, but you can find lots of references here (Programmer Certification forum).
If you ask for books, then "OCJP 6 K&B"is a very good reference. Other than that, "Effective Java" Joshua Bloch is also good one.
I think the NIIT book is kind of a "Work Book" type and that doesn't fulfill a reference type enough.
Hi Jim, The code itself doesn't make sense, since mostly no usable body in it.
What it is actually tying to do is, create a customized Iterator class, but lack of body code, nothing more.
All the collection interfaces implements Iterator, and tats just enough for normal use.

Next time try to post your code bit formatted
11 years ago

Two different objects, two different locks, so no mutual exclusion.


That's clear.

Again, Thank you for your concern and answer.
First of all, Thank you Jeff.

No, as long as both methods are static or both are non-static.


The answer No satisfies me, but what is the impact when we mixed up static and non-static while both are Synchronized (code block or method).
Means, one static synched code and one non-static synched code.

That sounds kind of bossy. Comments like that run the risk of alienating the people whose help you seek.


Ok, Sorry. I didn't mean to be bossy, but I implied solid as straight forward without wandering.
I'm still greenHorn
Hi Ranchers!
I have some questions regarding Synchronization.

It's true if the running instance of a synched method is locked by a thread, then
1. the specific synched code cannot be accessed by any other thread
2. any non-synched methods or code can be accessed by other threads

Question is, what is the type of restriction on another synched method / code block written in the very same class?
Can it be accessed by another thread? (at the same time, while the object is locked)

I think, since there is only one lock per object, it is not possible. BUT need confirmation.

Expects a solid answer