I am working in a Microsoft C# environment here (hostile territory ) so I showed this post to my colleagues.
We found that this is true for the primitive types like you showed in your example. However, when normal objects (another super and sub object) are used in C# then the best matching method is chosen, just as in Java.
So it seems the difference between C# and Java on this matter only has to do with primitive types. Still it is a bit strange of course…

C++:

method(double): 10
method(double): 3.2

Java:

method(int): 10
method(double): 3.2

C#:

method(double): 10
method(double): 3,2

What is happening here?

In C++ and C#, methods from superclasses are not automatically inherited into the subclass, as in Java. In Java, we are used to the fact that the compiler will look for the best matching method and call that. So, if you call method(…) with an int as a parameter, the method in the superclass will be called, because it matches exactly.

In C++ and C#, the compiler first looks if it can find a method in the subclass that it can use, even if the method doesn’t match exactly (i.e., it will use the method(double) in the subclass even though there is a method(int) in the subclass that matches exactly). Only if it can’t find a matching method, it looks in the superclass.

Note that you can make C++ behave the Java way - you’d have to add a ‘using’ statement to the subclass, like this (this is what was mentioned in Bjarne Stroustrup’s FAQ):

class Sub : public Super {
public:
using Super::method;

void method(double d) {
// … etc.
}
};

I don’t know how to do this in C# or if it is even possible (the C++ syntax doesn’t work).

I like the way Java does this better than how C++ and C# do it - it seems more logical to me to find an exactly matching method first.

Why does appFuse uses only jMock?
Why not strutstestcases, springframework.test or any other implementation of junit, though they are made for the use with appropriate framework.

In our project we’re using a SmartMX card featuring JCOP. The card is integrated into a (yet to be released) samsung phone that has a NFC Chip on board. This setup makes near field communication solutions possible.
And yes, there’s a smart card API available in java 6. Look at it closely and you’ll see it’s filled with byte(array)s. Although the API seems to support ints, the following can be read in the command APDU class comment: �For the header bytes CLA, INS, P1, and P2 the Java type int is used to represent the 8 bit unsigned values. In the constructors, only the 8 lowest bits of the int value specified by the application are significant. The accessor methods always return the byte as an unsigned value between 0 and 255.’

Thanks for referring to my article above; I am glad you found it a nice introductions… Yes there are other APIs to consider, such as SATSA and a newer Smart Card API for J2SE (JSR 268, Smart Card I/O API).

You can find more about Java Card, and SATSA at my website  thanks.

ceo

I agree with you that this is a realy tricky problem which is hard to detect, because the the deviation is only 1 percent.

Keep the tricky problems comin’!

-Willem