Static hard typing is useless is method signatures

Consider following interface method signatures:

AlfaRomeoTargetProduct getByPK(java.lang.Integer languageVersionId, java.lang.Integer alfaRomeoId);

SigmaOmegaTargetProduct getByPK(java.lang.Integer sigmaOmegaId, java.lang.Integer languageVersionId);

And several other such getByPK methods. These were generated by O/R Mapping software. They are parts of the same application and are used together.

I've just spend at least half an hour looking for reasons for code below to explode:

...
case SIGMA_OMEGA_TEASER_OBJECT_TYPE:
productId = sigmaOmegaTargetProductDAO.getByPK(myObjectId, lvId, true).getProductId();
break;

case ALFA_ROMEO_OBJECT_TYPE:
productId = alfaRomeoTargetProductDAO.getByPK(myObjectId, lvId).getProductId();
break;
...

Until I checked the actual O/R Mapping code for getByPK.

For quirky reasons order of method attributes is shifted between various objects - sometimes languageVersionId is first, sometimes last.

Guess what? It should have been:

productId = alfaRomeoTargetProductDAO.getByPK(lvId, myObjectId).getProductId();

Static hard typing haven't prevented this error. I could be writting this code in dynamic language and save a lot of time.

It get's worse..

Let's suppose method signatures are fixed and myObjectId is always first and there is one more attribute lvId.

With language like python or ruby we could just ommit the switch/case structure and write:

dao = getDaoByName('alfaRomeoTargetProduct')
productId = dao.getByPK(myObjectId, lvId).getProductId()

We can't in java. Unless all of these O/R Mapping objects were using the same interface. Which is unsupported in O/R Mapping we use. So sad..

Moral: Static hard typing is useless. Even if no errors/inconsequences are present, static hard typing is counterproductive.