Proposal: Enable the migration of Floating-Point Calculations from Math to StrictMath

[halibobo1205]

Simple Summary

     This proposal aims to activate the #87 network parameter to migrate the floating-point calculations from java.lang.Math to java.lang.StrictMath for cross-platform computational compatibility, for more details, please refer to TIP-697.

Motivation

     Up to GreatVoyage-v4.7.6(Anaximander), Java-Tron has utilized the class Math for floating-point calculations. However, the class Math may yield varying calculation results for identical inputs across different hardware platforms and JDK versions.
Looking ahead to potential cross-platform support and broader JDK version compatibility, Java-Tron needs to transition from java.lang.Math to a mathematical library that ensures consistent calculation results across platforms and newer JDK versions.

How to Initialize the Voting Request

• Open the pow calculation algorithm migration proposal.
  • createProposal 87 1

Backwards Compatibility

     Since consensus-affecting changes will only be activated post-proposal approval, this migration maintains backward compatibility and preserves consensus from the genesis block onward.

[Sunny6889]

@halibobo1205 in this case does the java-tron code changes PR submitted? if so could you share me the PR, if not when there will be PR changes

[halibobo1205]

@halibobo1205 in this case does the java-tron code changes PR submitted? if so could you share me the PR, if not when there will be PR changes

@DongDongSunny, implemented in GreatVoyage-v4.7.7 (Epicurus) by PR:

• feat(math): migrate pow operation from java.lang.Math to java.lang.StrictMath java-tron#6098

[xxo1shine]

@halibobo1205 After the proposal is passed, which platforms and JDK versions can Java-Tron support?

[CarlChaoCarl]

@halibobo1205
Math is more performant in most cases because platform math libraries are usually optimized.
What I want to know is whether there is actual performance data for Java-Tron transitioning from java.lang.Math to java.lang.StrictMath.

[CooperDepp]

@halibobo1205 This is definitely an important step. And I wonder except for the floating-point calculations, are there any other limitations to clear up before we could support arm platforms?

[halibobo1205]

@xxo1shine @CooperDepp, This is one of the requirements for extending platforms and JDK versions, such as supporting the arm platform based on JDK17. Other improvements include dependency updates, code adaptation, etc.

[halibobo1205]

performance

base: x86_64 ,16C 32G, java version "1.8.0_161"
bancor exchange: Time consumed is almost the same: 310+ ns.

DynamicEnergy: exponent is mostly 1, for better performance by StrictMath.

[CooperDepp]

@xxo1shine @CooperDepp, This is one of the requirements for extending platforms and JDK versions, such as supporting the arm platform based on JDK17. Other improvements include dependency updates, code adaptation, etc.

Thank you, and now java-tron only supports x86 platform right? What other platforms will TRON support in the future?

[halibobo1205]

@CooperDepp , java-tron still only supports the x86 platform, TRON will support arm64 platforms in the future.

[Tinabates]

I don’t know how to bring the contract to my wallet smh

[Tinabates]

Thank you

[halibobo1205]

I don’t know how to bring the contract to my wallet smh

@Tinabates , please go here https://github.com/tronprotocol/java-tron/issues for more help!

[Murphytron]

This proposal has been effected since 2025-01-20 14:00:00 on TRON mainnet, with 23 SR approvals.

[Tinabates]

I need access to my tron account is been over a year and I still have no access but Binance and the rest of these voting SRs have access to my accounts why is this instead of passing me my own funds would they transfer my accounts to there partners. Kind of fishy and kraken too they alll just want to tie up my funds as long as possible they are in cahootz/ collusion