java-tron: Running a TRON Full Node in Java

The gap java-tron fills for TRON operators

TRON is a public chain, but the chain is only reachable through software that speaks its wire protocol, validates blocks and serves the HTTP and RPC endpoints clients use. java-tron is that software, written in Java and described in the README as the Java implementation of the TRON Protocol. The README frames the network as a high-throughput chain using DPoS consensus with a claimed 2000+ TPS, plus a TRON Virtual Machine that is EVM-compatible for contract execution.

The audience is narrower than the repository's visibility suggests. A full node is not a wallet and not a client library. The README describes it as a gateway that exposes HTTP and RPC interfaces through which clients transfer assets, deploy contracts and call on-chain logic. If you are building a service that reads TRON state or submits transactions, you are more likely to point that service at someone else's node than to run your own. You run java-tron when you want the endpoint to be yours: a Super Representative candidate, an exchange that needs its own view of the chain, a team testing governance proposals on Nile before they reach Mainnet, or an operator standing up a private network.

The README does not market the project as a general Java library. It ships as a node binary with a maintenance toolkit, and the hardware table makes the intent clear: this is infrastructure, not a dependency you drop into an application.

How the node, the toolkit and the config files fit together

The build produces runnable artifacts rather than a published library. FullNode.jar is the main executable and runs as a full node by default; the README points to `java -jar FullNode.jar --help` for command line options. Toolkit.jar is a separate node management utility for partition, prune, copy and convert operations on databases, plus a shadow-fork tool. start.sh is a quick start script for x86_64 on JDK 8 that downloads, builds and runs FullNode.jar, and start.sh.simple is a template for ARM64 on JDK 17.

Network selection happens at startup through configuration files, not through a flag that switches chains. The README names three: reference.conf as the built-in template, config.conf for Mainnet, and config-nile.conf for the Nile testnet, which lives in the nile-testnet repository rather than this one. That is a meaningful design choice for operators: the config file is the unit of deployment, so a Mainnet node and a Nile node differ by which file you pass, and the parameters inside it.

The repository layout backs this up. The top level carries chainbase, consensus, crypto, protocol, actuator, framework and plugins as separate Gradle modules, with the protobuf definitions in their own module and a separate document for the wire protocol. The consensus module is separate from chainbase, and the actuator module holds the on-chain operations. For anyone reading the source to understand behaviour, that separation is the map: protocol definitions in one place, state storage in another, and the operations that mutate state in a third.

One practical consequence of a config-driven node is that the README does not document rollback or downgrade steps between releases. The release names change with each version, and nothing in the README describes what happens to the database when you run an older jar against a newer one.

Installing java-tron and starting a node

The README states the build prerequisites plainly: at least 4 CPU cores, 16 GB of RAM and 10 GB of free disk space for compilation, on Linux or macOS. Windows is not supported. The JDK is tied to the CPU architecture and the two are not interchangeable, so check this before anything else: x86_64 and amd64 need JDK 8, ARM64 and aarch64 need JDK 17. ARM64 support begins with GreatVoyage-v4.8.1, according to the README note.

Dependencies can be installed with the script in the repository root:

chmod +x install_dependencies.sh
./install_dependencies.sh

The README calls this the recommended option for quick setup and offers a manual path through the installation guide for anyone who wants to see each step.

With dependencies in place, clone and build. The README checks out the master branch and skips tests:

git clone https://github.com/tronprotocol/java-tron.git
cd java-tron
git checkout -t origin/master
./gradlew clean build -x test

The `-x test` parameter skips test execution, which is what makes this practical on a build machine that is not sized for the full suite. A successful build leaves FullNode.jar in build/libs/. From there you start the node with a configuration file for the network you want, and the README's own reference for Mainnet is config.conf under framework/src/main/resources.

Before running anything against Mainnet, read the hardware table rather than the build table. Compilation needs 4 cores and 16 GB; a stable full node with full storage is listed at 8 cores, 32 GB and 3.5 TB of SSD, and the recommended tier is 16 or more cores, 32 GB or more, and 4 TB. The gap between the two tables is the first thing that surprises people who build successfully and then try to sync.

Where java-tron is the wrong choice

The most common mismatch is treating a node as a client library. If your application only needs to create accounts, sign transactions or query balances, running a full node means accepting the hardware table, the sync time and the disk growth of a chain node in exchange for an endpoint an SDK could give you. The README's own framing supports this: the node is a gateway, and clients connect to it. The related search terms around wallets and SDKs reflect that split, and java-tron does not present itself as the answer to either.

The second limitation is the platform constraint. Windows is not supported for building, and the JDK requirement is architecture-specific, so a team standardized on JDK 11 or JDK 21 on x86_64 has no documented path here; the README gives JDK 8 for that architecture and JDK 17 for ARM64, and says the two are not interchangeable. That is a real constraint on mixed fleets, where the same build pipeline may need to produce a jar for both an x86_64 host and an ARM64 host.

The third is operational. Toolkit.jar exists precisely because node maintenance is not trivial: partition, prune, copy and convert operations on the database are separate commands, and the shadow-fork tool is there for a reason. A team without someone who can reason about database state and disk usage will find the node harder to keep alive than the install steps suggest. The README documents the tools but does not document a rollback path between releases, which is the gap to test on a testnet before you need it on Mainnet.

How java-tron differs from SDK-based access to TRON

The real alternative for most teams is not another node implementation but a different layer: an SDK or a hosted RPC endpoint. The difference in approach is where the trust and the operational burden sit. With java-tron you validate and serve the chain yourself, which means you control the endpoint, you see the blocks as the node sees them, and you are responsible for storage, memory, bandwidth and upgrades. With an SDK or a hosted endpoint you write against an API and let someone else run the node, which removes the hardware table from your problem entirely but also removes your independent view of the chain.

That distinction matters most for the roles the README describes. A Super Representative candidate has no substitute: consensus participation requires running the node. An exchange that needs its own view of deposits and withdrawals has a strong reason to run one. A developer testing a contract on Shasta, which the README says mirrors Mainnet's features and governance proposals, can often use a public endpoint and skip the 4 TB of SSD. Nile is described as ahead of Mainnet, which is where you would go to see a governance proposal before it lands.

The configuration model reinforces the difference. Because network selection is a config file, the same jar serves Mainnet, Nile and a private network, and the README explicitly lists private networks as a supported case. An SDK cannot give you a private chain; only a node implementation can. That is the capability that justifies the operational cost, and it is the one to weigh against simply calling an endpoint.

Licence, releases and the cost of staying current

java-tron is licensed under LGPL-3.0. The practical implication for most operators is limited, because running a node is use rather than distribution. It becomes a question when you modify the code and distribute the result, or when you link it into a product you ship; the LICENSE file in the repository is the authoritative text, and this is a matter for your own counsel rather than something to settle from a summary. The README lists a separate Integrity Check section, which suggests verifying downloaded artifacts is part of the intended workflow.

The release cadence is visible in the tags. GreatVoyage-v4.8.2, v4.8.2.1 and v4.8.2.2 arrived on 2026-07-15, 2026-07-31 and 2026-09-08 respectively, each with a codename attached. The last push to the develop branch was on 2026-09-22. Three releases inside two months is a fast cadence for infrastructure, and it means the upgrade cost is not a one-time task. Each release can carry consensus or protocol changes, and the README does not describe a downgrade procedure, so the operational question is not whether to upgrade but how to rehearse it.

That rehearsal is where Nile and Shasta earn their place. The README describes Nile as typically ahead of Mainnet and Shasta as kept in sync with Mainnet's parameters and software versions, which gives two different testing postures: Nile for features before they ship, Shasta for a realistic run of the version you are about to deploy. Budgeting for that cycle, rather than treating each release as a drop-in jar swap, is the honest cost of running this software.

Editorial conclusion

Adopt java-tron if you need a TRON full node, a private network or a Shasta/Nile mirror, and you can supply the hardware the README lists: 8 cores, 16 GB of RAM and a 200 GB SSD at the minimum tier, or 4 TB for the recommended one. Do not adopt it if you only want to sign transactions or read balances; an SDK is the smaller dependency. Before committing, verify your CPU architecture against the JDK table, because x86_64 needs JDK 8 and ARM64 needs JDK 17, and read the LGPL-3.0 terms against how you intend to distribute your build.

Frequently asked questions

Official sources

1. Issues
2. License: LGPL-3.0
3. README
4. Releases
5. tronprotocol/java-tron on GitHub