mkalinin
commented
5 years ago There is a SolcJ project which supports 0.5.6 solidity version since this PR was merged https://github.com/ether-camp/solcJ/pull/20. EthereumJ uses its old version, updating it is the first thing worth to do in order to start supporting solidity 0.5.x. It requires tests fixes as this update gonna bring some incompatible API changes.
There is another inconvenience: SolcJ is just a Java bridge for solc compiler while compiler API and ABI stuff sits in EthereumJ codebase. There is an issue that requests a segregation of solidity stuff from EthereumJ https://github.com/ether-camp/solcJ/issues/14.
Alternatively, perhaps this project could be restructured so that users can define their own Solidity version as part of their build script?
This feature could, also, become a part of SolcJ. From my perspective it makes sense to work on the segregation straightaway and when it's done use SolcJ as a fully feature solc provider in EthereumJ and other projects that requires rich Solidity support.
tbocek
derekzuk
I believe that Solidity 5.x is now considered released/stable. It would be very nice if this project upgraded so users can leverage new Solidity features (some of which are significant).
Alternatively, perhaps this project could be restructured so that users can define their own Solidity version as part of their build script? I haven't thought through how this would work exactly, but presumably as part of the build process it would fetch the binary releases of the version specified as part of the build process, rather than requiring that they be pre-bundled into solcj and then pulled in as a traditional dependency.