Overloading with different int types produces an error in generated Java Wrapper class

[Julius278]

Issue_title

Overloading is in Solidity as in Java no bigger problem. Its different when it comes to generating signed and unsigned integers.

Issue_description

here is a test smart contract to reproduce the issue:

`contract TestContract {

mapping(string => int) private intValues;
mapping(string => uint) private uintValues;
mapping(string => string) private stringValues;

function putValue(string memory key, int value) public {
    intValues[key] = value;
}

function putValue(string memory key, uint value) public {
    uintValues[key] = value;
}

function putValue(string memory key, string memory value) public {
    stringValues[key] = value;
}

}`

when you generate the Java Wrapper code, it produces this error:

Issue_context

I know that Java Integer, Long or BigInteger have value ranges as Solidity int (int256) and there are no unsigned integer values. But has someone already thought about overloading like in the above scenario?

[Julius278]

And sometimes there is existing code in a project which you cant change that easy :)
But without really using it, the generated class wont compile.

Or if I dont need this "putValue" function, is there a chance to ignore it during wrapper code generation?

[gtebrean]

@Julius278 thanks for pointing this out, we are aware of it. We tried in the past to work on this but was kind of hard to find a solution as we want it to keep it generic too.

We don't have a concrete solution for the wrapper generation moment, you can comment out one of the methods, but is not the smartest thing.

Also in the past we tend to do generate smart contracts wrappers with method1 and method2 for the methods which were overloading, would it be a solution for you?

[gtebrean]

btw @Julius278 as I see you are interested in Web3j I'm working now on planning an online Hyperledger Web3j Summit to getter as much feedback as possible from users. Please add me on Linkedin to give more details if you are interested in. https://www.linkedin.com/in/george-tebrean/

[Julius278]

Hey @gtebrean,
I had feared that :D

Keeping it generic is a good way, I will also think about it in a quite minute.

Okay, my workaround was to deploy it via JavaScript and not generate the contract (it's only used in other contracts, not directly from a user).

I'll have to check with some colleagues if we can rename the overloaded functions.

Best regards,
Julius

[rohandakua]

Hello Guys
Can't this be solved by using a custom class that has two fields i.e

1. BigInteger
2. flag for indicating signed or unsigned

and instead of overloading the functions in java , just having if else statement.

This is just a thought of mine . I don't know the background working of this .

[gtebrean]

Thanks @rohandakua for your suggestion, we are taking it in the consideration. Also for next 2 weeks I will be of, so if any of you would like to contribute and to propose any PR until I'm back feel free.