Luca Romanello

Greenhorn
+ Follow
since May 30, 2002
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 Luca Romanello

Hi all
I don't know if I understood it right, but with HashSet, LinkedHashSet etc etc, testing whether an object is or isn't present in the Collection is a two-step process: firstly, the object's hashCode is calculated and searched amongst the "buckets" labelled by the already inserted objects' hashCodes, then, if it is found, the method equals() is run against all the object within the found bucket.
HashCode doesn't say us which objects are the same, but different hashCodes SHOULD always tell us that their instances are different.
Hope this helps
Regards
LR
[ December 11, 2007: Message edited by: Luca Romanello ]
Hi
I think the point is you're not obtaining what you want because you are not synchronizing the same object, but two different ones. That means that thread a's myMethod will be locked for every object accessing it (that is, just a itself), and the same goes for b's myMethod. Two different instances = two different locks.
Try with this (a little strange, I know):

That means, two different threads accessing the same Runnable instance.
Hope this helps
Regards
LR
[ December 10, 2007: Message edited by: Luca Romanello ]
Hi all
I think the main reason is 'cause Interfaces are just contracts, they are in no way related to any instance. You can't instantiate an Interface (though you can make an assignment of an instance to a Interface reference and make an instanceof test - and, yes, you actually CAN, anonimously, but that's not the point). If a Class implements an Interface, the Class has to fulfill Interface's contract and it will be Class's responsability to declare (and use) non final variable.
Hope this helps
Regards
LR

Originally posted by Marcus Jastrebowski:
Thanks R, and so, after a little bit of fiddling around, I was able to satisfy this requirement: "In reverse(), check if the String has a length of 0 by using String.length() method. If the length is 0, the reverse() method will throw exception." The code gets considerably longer that way, but I guess the idea of this particular exercise was to show how the exceptions are propagated up the stack from one method to another.

Here is the reworked version, and it seems to be working fine now.



Hi Marcus
Please note that if you pass a String with length == 0 to your code, you will obtain an uncaught exception, since in main() you handle ArrayIndexOutOfBoundsException, but not IndexOutOfBoundsException (which, being a subclass of RuntimeException, hasn't to be declared in the throws class of method reverse() but, being a superclass of ArrayIndexOutOfBoundsException, isn't handled by the catches you wrote). The code works, though, passing no parameter. Is this correct (that is, is this what you really wanted )?
Hope this helps
Regards
LR
Hi all
I previously (here and maybe in another thread) stated that short range was between -128 and 127. This is an error I deeply apologize for: that range is byte's and not short's.
Sorry
Regards
LR
Sorry, Ishmayel, but I'm missing your point here.
From what you write, it seems to me we're not understanding each other on the boolean operation you wrote in your post.
Maybe with a little example my thought is clearer:
( (b1 = false) | (b1 & b3) | (b1 | b2) ) => returns false
( (b1 == false) | (b1 & b3) | (b1 | b2)) => returns true
Hope this helps (unless at this point of the day I am too tired to think properly... )
Regards
LR

Originally posted by ishmayel vemuru:
Hi I had Little bit confusion..If you don't mind can any one explain please.

Boolean b1 = true;
boolean b2 = false;
boolean b3 = true;


why this if((b1 = false) | (b1 & b3) | (b1 | b2)) is returning the false....I am thinking this will return true..like this

b1 = false) | (b1 & b3) | (b1 | b2)
------------|-----------| ---------
false | true | false
------------------------|------
true |false = true

but when test this this is returning the false
If there is any wrong in my evaluation...Please any one explain.
Thanks in advance.



Hi Ishmayel
Pay attention to the first part of your boolean expression: it's b1 = false and not b1 == false. This means that you are assigning to b1 the value false, thus returning the result of the assignment (again false). After the first part is evaluated, comes the second term, b1 & b3, which return false and not true, 'cause now b1 isn't true anymore.
Hope this helps
Regards
LR

Originally posted by ishmayel vemuru:
class Feline
{
public static void main(String[] args)
{
Long x = 42L;
Long y = 44L;
System.out.print(" " + 7 + 2 + " "); // line---1
System.out.print(foo() + x + 5 + " "); //line--2
System.out.println(x + y + foo()); //line--3
}
static String foo() { return "foo"; }
}
Out Put:
72 foo425 86foo

Can any one explain the Concatination operator " + " at line 1, line 2 performing as a string concatination but at line 3 that is performing as addition operator...I'm confusing with this Please help me any one as early as possible.
Thanks in advance...
Ishmayel.



Hi Ishmayel
The sum at line 3 gives an output of "86foo" because all atomic operations of the same kind are resolved from left to right (unless there are brackets, which change resolving order). This means that in

x + y is resolved before all, and since there are NO String OPERANDS (being x and y Long), the jvm read the '+' operator as a sum and not as a concatenation. After "x + y" is evaluated (giving a result of 86), the second '+' sign is read as a concatenation because method foo() returns the String operand needed for the jvm to behave this way and so the output is "86foo". The above code is equal to:

For the first 2 System.out.print(), all the '+' signs are read as concatenation operators because there is a String operand since the first atomic operation (" " and foo()), so they can be interpreted as:

Hope this helps
Regards
LR

Originally posted by Nabila Mohammad:
I got the "==" part
How about the equals() part..?



Hi Mohammad
Both "==" and equals() will return false BEFORE assigning obj2 to obj1, unless class MyClass overrides the inherited (from Object) method equals() so to make it return true. If MyClass doesn't override it, the jvm will use Object's equals() which will run a "==" test:

This is the same reason why testing AFTER assigning obj2 to obj1 will return true in both cases (being a) the same instance and b) basically the same test). The key here is whether method equals() has or hasn't been overridden.

Edit: as for your last post, no output is shown just because of the same reason, method equals() wasn't overridden, so both "==" and equals() will return false, being two different references and two different instances. If you overrides method equals() this way:

then the main will print out "look at that pretty car.", 'cause equality will be tested against Car's member model and not against object reference...
Hope this helps
Regards
LR
[ November 21, 2007: Message edited by: Luca Romanello ]
Hi all
The uncommented code produces a different output just for i3 and i4: that's because their literal value is in "byte range" (= between -128 and 127) and the jvm, to save memory, behaves similarly to the String constant pool (= assigning two reference to the same object in heap). This behaviour of Short and Integer is the same for Boolean, Byte and Character (from \u0000 to \u007f), too (I would say, all that is possibly in "byte-or-below range" ).
Hope this helps
Regards
LR

[ November 20, 2007: Message edited by: Luca Romanello ]
[ November 22, 2007: Message edited by: Luca Romanello ]

Originally posted by R van Vliet:




Hi all
I respectfully disagree with your example. All boolean tests return true, since assigning String literal to String variables means that the jvm take advantage of its String constant pool - so s1 and s2, though both initialized without referencing each other, point to the same object (String) in the pool.
The example made by Fudong is correct, since both str1 and str2 make an explicit call to String constructor, creating two new (and different) instances.
We can find the same (or - better - very similar) behaviour working with int literals in short range (between -128 and 127; even if assigning them to a wrapper via boxing should mean making a new constructor call ):

will print true, while assigning 128 to s1 and s2 will print false.
Hope this helps.
Regards
LR
[ November 20, 2007: Message edited by: Luca Romanello ]