Java SDK - two different classes for "Account"

Hi all,

With the introduction of the v2 API, we now have 2 different “Account” Classes in Java SDK:

1) com.algorand.algosdk.account.Account
2) com.algorand.algosdk.v2.client.model.Account

As far as I understand, we should use the second one (v2), but this doen’t seem possible because you can only sign a transaction using the first one.

Am I missing something?

Are they intended to have different use cases?
If so, since they have the same name, it’s a bit annoying and confusing in Java to have to handle both because it forces you to use the extended class name (i.e. com.algorand.algosdk.v2.client.model.Account) to refere to the correct “Account”.

What is your opinion on this? Do you have any suggestions?


We really need to change this, but the com.algorand.algosdk.v2.client.model.Account is used with rest calls. The com.algorand.algosdk.account.Account class is used for signing and other things (multisigs etc) that can be done on or offline.

They have two very different purposes.

The first one represents an Account you can use to sign transactions with (the simplest case being just a secret signature key). If you want to sign and send transactions, that’s what you want to use.

The second one represents an account state on the blockchain.
It corresponds to Algorand Developer Docs
That is what you get when you query account information, i.e., java-algorand-sdk/ at develop · algorand/java-algorand-sdk · GitHub / Algorand Developer Docs

Thank you, much clearer now.

Unfortunately it’s confusing (and annoying while coding) that they have the same name… but I think it would be too difficult now to change the SDK to resolve this homonymy.
Perhaps I could propose to encapsulate one of the classes in another one with a different name…
Do you see any other solution?

I guess this is because the original code is written in Go.
In Go classes are always prefixed by the package name. So you never have such an issue.

Maybe it would be good to add some comments in the documentation to make that clear.