Tilo Hemp

Ranch Hand
+ Follow
since Nov 21, 2005
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 Tilo Hemp


as far as I understand, it probably would be possible to let RecordNotFoundException inherit from IOException, as long as it is well motivated... for example, FileNotFoundException also inherits from IOException.

Actually, I am planning to extend both Exceptions appearing in the interface from a common parent (not IOException), because both indicate a database problem.

This makes life easier when it comes to the remote calls, and adds an extra layer of abstraction from the concrete implementation.

Any comments are appreciated...
Here is another correct solution

It is based on the idea to redefine System.out.println(Object o)
This method is redefined to always print "Woof".

The newDog variable is assigned null, so the redefined System.out.println is actually called with null, but prints "Woof", because it is redefined.

The redefinition has to be wrapped into one statement that returns null (as we are only allowed to insert something into the line Dog newDog = ...;

The full code looks like this (it works, I tried it)

[ November 18, 2006: Message edited by: Tilo Hemp ]
[ November 18, 2006: Message edited by: Tilo Hemp ]
the code
StringBuilder sb = new StringBuilder("abcde");
System.out.println(sb.insert(1, sb));

produces aaaaaabcde

--> neither aabcdebcde nor infinite recursion... neither fish nor fowl

Obviously, the fields of ancestors of an interface are only initialized when the corresponding interface they are declared in is accessed first (and not, how it would be expected for classes, when the child interface is loaded).

To make it clearer: when a static field of a class is first accessed, all ancestor classes are loaded recursively, including the initialization of the respective static fields.

On the other hand, when a (always static) field of an interface is first accessed, the fields of it's ancestors are not initialized. Only it's own fields are initialized.

The following code demonstrates this:

...just for completeness:


although personally i prefer java
16 years ago
i think there is a little mistake in trips & traps:

No inner class can have a static member.

should be changed to

No non-static inner class can have a static member.

just a remark: if the method in A is private, you can't even access it in B, so you can't override it either. But you are free to redeclare it. In this case, it is treated as a completely distinct function (ie. no polymorphism would apply).


je pense que c'est meilleur de parler en anglais parce que plus de ranchers comprend ca. En plus, je crois que l'examen sera en anglais...

The variables local to a method live on the stack, while object variables (ie. fields of the object) are stored together with the object, which is on the heap. In both cases, you can have reference variables, so reference variables can both be stored on the stack and on the heap.

hello mithun,

yes, i made a mistake, this is meant to be an example where check() returns <true>, ie. x != y. if the other synchronized method (ie. setY()) is executed , then a subsequent call to check() would return <false>.

hi mohamed,

here are my thoughts about the questions:

first question:
A) is clearly "no". example:
assume x and y are zero. one thread (say "t1") executes setXY(5). after it has executed setX(5), it releases the object's lock. at this moment, another thread "t2" executes check(), returning <false>.

B) is a somewhat confusing question, because it does not say anything about the thread "t2" in the above example. basically, calling setXY() with multiple threads will not perpetually make i != j. but calling it with multiple threads while simultaneously calling check() with another thread might still return <false> (as in A). so i would answer "yes".

C) assuming "seperately" means "not through setXY, but directly", then the answer is "no", because they are private methods and can only be called through setXY.

D) "no" based on my above answer to "A"

Second question:
A) i assume the code will not run with 1.3 --> execution of main() method is skipped --> i.e. execution of ALL statements is skipped --> assertion statements are skipped --> then the answer is clearly "yes"
if my assumption is correct, this is an example of an imo ill-defined question, where you have to change the meaning of the question by yourself to answer it 'correctly' (in this case, you have to add "...but the other statements are not skipped").

I would say B is "yes", because "appropriate command line switch" may include "no command line switch"

as you may have noticed, some of these answers are highly subjective

[ March 16, 2006: Message edited by: Tilo Hemp ]
hi mi,

you don't overwrite the equals() method. the inherited implementation in Object just tests for reference equality.

you get false because you create two different objects (--> unequal references).

[ March 14, 2006: Message edited by: Tilo Hemp ]
hi jon,

i can't contribute to the DecimalFormat question, but if you only need to do this conversion a few times, it might not be worth the creation of an additional object. in this case, i would prefer a hand-made code, e.g.

double fact = Math.pow(10, nDigits);
double rounded = Math.round(x*fact) / fact;

nDigits is the decimal place you want to round to. anyway, remember that the results might not be accurate, as the number of digits stored in the floating point numbers are finite. for example,


prints 9999999.0 as there is not enough place in the float to store the fraction exactly.

16 years ago
thanks a lot marc, this is quite funny!
especially, putting this quotation in a small margin under short and to-the-point statements
Hi Marc,

thanks a lot for the interesting information!

I've got one remark and one question:

NaN is non-ordinal, so relational comparisons involving NaN always result in false. The only exception is NaN != NaN, which returns true.

--> the exception is not limited to NaN != NaN, but can also applied to say Double.NaN != 12.34, which also gives true. I guess != simply inverts the output of ==.

And my question is: what does "Cuius rei demonstrationem mirabilem sane detexi hanc marginis exiguitas non caperet." mean? I tried to find an automated latin-translator, but this did not work out

one thing to note about these "constants" is that the compiler checking is only done when declaration and initialzation are done in the same statement:
final byte x ;
x = 10;
char c = x;
--> won't compile!