fix: spotlessApply

Signed-off-by: Naydenov <nikola.naydenov@limechain.tech>

sdk/src/main/java/org/hiero/sdk/AccountAllowanceApproveTransaction.java

@@ -26,7 +26,6 @@
  * account, now or in the future (if `approved_for_all` is set).
  *
  **/
-
 public class AccountAllowanceApproveTransaction extends Transaction<AccountAllowanceApproveTransaction> {
     private final List<HbarAllowance> hbarAllowances = new ArrayList<>();
     private final List<TokenAllowance> tokenAllowances = new ArrayList<>();

sdk/src/main/java/org/hiero/sdk/AccountAllowanceDeleteTransaction.java

@@ -22,15 +22,15 @@
  * Given one or more, previously approved, allowances for non-fungible/unique
  * tokens to be transferred by a spending account from an owning account;
  * this transaction removes a specified set of those allowances.
-
+ *
  * The owner account for each listed allowance MUST sign this transaction.
  * Allowances for HBAR cannot be removed with this transaction. The owner
  * account MUST submit a new `cryptoApproveAllowance` transaction with the
  * amount set to `0` to "remove" that allowance.
  * Allowances for fungible/common tokens cannot be removed with this
  * transaction. The owner account MUST submit a new `cryptoApproveAllowance`
  * transaction with the amount set to `0` to "remove" that allowance.
-
+ *
  * ### Block Stream Effects
  * None
  */

sdk/src/main/java/org/hiero/sdk/AccountDeleteTransaction.java

@@ -16,7 +16,7 @@
  * Delete an account.<br/>
  * This will mark an account deleted, and transfer all tokens to a "sweep"
  * account.
-
+ *
  * A deleted account SHALL NOT hold a balance in any token type.<br/>
  * A deleted account SHALL remain in state until it expires.<br/>
  * Transfers that would increase the balance of a deleted account
@@ -25,7 +25,7 @@
  * its expiration.<br/>
  * When a deleted account expires it SHALL be removed entirely, and SHALL NOT
  * be archived.
-
+ *
  * ### Block Stream Effects
  * None
  */

sdk/src/main/java/org/hiero/sdk/AccountUpdateTransaction.java

@@ -19,7 +19,7 @@
 
 /**
  * Modify the current state of an account.
-
+ *
  * ### Requirements
  * - The `key` for this account MUST sign all account update transactions.
  * - If the `key` field is set for this transaction, then _both_ the current
@@ -32,7 +32,7 @@
  *   updated on success.
  * - All fields that may be modified in this transaction SHALL have a
  *   default value of unset (a.k.a. `null`).
-
+ *
  * ### Block Stream Effects
  * None
  */

sdk/src/main/java/org/hiero/sdk/ContractCreateTransaction.java

@@ -286,9 +286,9 @@ public ContractCreateTransaction setInitialBalance(Hbar initialBalance) {
 
     /**
      * @deprecated with no replacement
-
+     *
      * Extract the proxy account id.
-
+     *
      * @return                          the proxy account id
      */
     @Deprecated

sdk/src/main/java/org/hiero/sdk/ContractDeleteTransaction.java

@@ -15,10 +15,10 @@
 /**
  * Delete a smart contract, and transfer any remaining HBAR balance to a
  * designated account.
-
+ *
  * If this call succeeds then all subsequent calls to that smart contract
  * SHALL execute the `0x0` opcode, as required for EVM equivalence.
-
+ *
  * ### Requirements
  *  - An account or smart contract MUST be designated to receive all remaining
  *    account balances.
@@ -35,7 +35,7 @@
  *    internal system use when purging the smart contract from state. Any user
  *    transaction with that field set SHALL be rejected and a response code
  *    `PERMANENT_REMOVAL_REQUIRES_SYSTEM_INITIATION` SHALL be set.
-
+ *
  * ### Block Stream Effects
  * None
  */

sdk/src/main/java/org/hiero/sdk/ContractExecuteTransaction.java

@@ -149,7 +149,7 @@ public ByteString getFunctionParameters() {
      * <p>
      * Use this instead of {@link #setFunction(String, ContractFunctionParameters)} if you have already
      * pre-encoded a solidity function call.
-
+     *
      * This MUST contain The application binary interface (ABI) encoding of the
      * function call per the Ethereum contract ABI standard, giving the
      * function signature and arguments being passed to the function.

sdk/src/main/java/org/hiero/sdk/EthereumTransaction.java

@@ -19,11 +19,11 @@
  * Make an Ethereum transaction "call" with all data in Ethereum formats,
  * including the contract alias. Call data may be in the transaction, or
  * stored within an Hedera File.
-
+ *
  * The caller MAY offer additional gas above what is offered in the call data,
  * but MAY be charged up to 80% of that value if the amount required is less
  * than this "floor" amount.
-
+ *
  * ### Block Stream Effects
  * An `EthereumOutput` message SHALL be emitted for each transaction.
  */

sdk/src/main/java/org/hiero/sdk/FileAppendTransaction.java

@@ -24,18 +24,18 @@
  * file, append more data until the full content is stored, verify the file is
  * correct, then update the file entry with any final metadata changes (e.g.
  * adding threshold keys and removing the initial upload key).
-
+ *
  * Each append transaction MUST remain within the total transaction size limit
  * for the network (typically 6144 bytes).<br/>
  * The total size of a file MUST remain within the maximum file size limit for
  * the network (typically 1048576 bytes).
-
+ *
  * #### Signature Requirements
  * Append transactions MUST have signatures from _all_ keys in the `KeyList`
  * assigned to the `keys` field of the file.<br/>
  * See the [File Service](#FileService) specification for a detailed
  * explanation of the signature requirements for all file transactions.
-
+ *
  * ### Block Stream Effects
  * None
  */

sdk/src/main/java/org/hiero/sdk/FileCreateTransaction.java

@@ -20,12 +20,12 @@
 
 /**
  * Create a new file.
-
+ *
  * If successful, the new file SHALL contain the (possibly empty) content
  * provided in the `contents` field.<br/>
  * When the current consensus time exceeds the `expirationTime` value, the
  * network SHALL expire the file, and MAY archive the state entry.
-
+ *
  * #### Signature Requirements
  * The HFS manages file authorization in a manner that can be confusing.
  * The core element of file authorization is the `keys` field,
@@ -45,16 +45,16 @@
  * including additional `ThresholdKey` or `KeyList` descendants) may be
  * assigned as the sole entry in a file `keys` field to ensure all transactions
  * have the same signature requirements.
-
+ *
  * If the `keys` field is an empty `KeyList`, then the file SHALL be immutable
  * and the only transaction permitted to modify that file SHALL be a
  * `fileUpdate` transaction with _only_ the `expirationTime` set.
-
+ *
  * #### Shard and Realm
  * The current API ignores shardID and realmID. All files are created in
  * shard 0 and realm 0. Future versions of the API may support multiple
  * realms and multiple shards.
-
+ *
  * ### Block Stream Effects
  * After the file is created, the FileID for it SHALL be returned in the
  * transaction receipt, and SHALL be recorded in the transaction record.

sdk/src/main/java/org/hiero/sdk/FileUpdateTransaction.java

@@ -22,12 +22,12 @@
 /**
  * Update the metadata, and/or replace the content, of a file in the
  * Hedera File Service (HFS).
-
+ *
  * Any field which is not set (i.e. is null) in this message, other than
  * `fileID`, SHALL be ignored.<br/>
  * If the `keys` list for the identified file is an empty `KeyList`, then
  * this message MUST NOT set any field except `expirationTime`.
-
+ *
  * #### Signature Requirements
  * Every `Key` in the `keys` list for the identified file MUST sign this
  * transaction, if any field other than `expirationTime` is to be updated.<br/>
@@ -37,10 +37,10 @@
  * field except `expirationTime`.<br/>
  * See the [File Service](#FileService) specification for a detailed
  * explanation of the signature requirements for all file transactions.
-
+ *
  * ### Block Stream Effects
  * None
-
+ *
  * See <a href="https://docs.hedera.com/guides/docs/sdks/file-storage/update-a-file">Hedera Documentation</a>
  */
 public final class FileUpdateTransaction extends Transaction<FileUpdateTransaction> {

sdk/src/main/java/org/hiero/sdk/FreezeTransaction.java

@@ -19,12 +19,12 @@
 
 /**
  * A transaction body for all five freeze transactions.
-
+ *
  * Combining five different transactions into a single message, this
  * transaction body MUST support options to schedule a freeze, abort a
  * scheduled freeze, prepare a software upgrade, prepare a telemetry
  * upgrade, or initiate a software upgrade.
-
+ *
  * For a scheduled freeze, at the scheduled time, according to
  * network consensus time
  *   - A freeze (`FREEZE_ONLY`) causes the network nodes to stop creating
@@ -34,7 +34,7 @@
  *     creating events or accepting transactions, and upgrade the node software
  *     from a previously prepared upgrade package. The network nodes then
  *     restart and rejoin the network after upgrading.
-
+ *
  * For other freeze types, immediately upon processing the freeze transaction
  *   - A Freeze Abort (`FREEZE_ABORT`) cancels any pending scheduled freeze.
  *   - A prepare upgrade (`PREPARE_UPGRADE`) begins to extract the contents of
@@ -43,7 +43,7 @@
  *     extract a telemetry upgrade package to the local filesystem and signal
  *     other software on the machine to upgrade, without impacting the node or
  *     network processing.
-
+ *
  * ### Block Stream Effects
  * Unknown
  */
@@ -271,7 +271,7 @@ public FreezeType getFreezeType() {
      * transactions in the same transaction body. Depending on this value
      * the service may schedule a freeze, prepare upgrades, perform upgrades,
      * or even abort a previously scheduled freeze.
-
+     *
      * {@link org.hiero.sdk.FreezeTransaction}
      *
      * @param freezeType                the freeze type

sdk/src/main/java/org/hiero/sdk/LiveHashAddTransaction.java

@@ -20,7 +20,7 @@
 
 /**
  * A Live Hash value associating some item of content to an account.
-
+ *
  * This message represents a desired entry in the ledger for a SHA-384
  * hash of some content, an associated specific account, a list of authorized
  * keys, and a duration the live hash is "valid".

sdk/src/main/java/org/hiero/sdk/LiveHashDeleteTransaction.java

@@ -16,10 +16,10 @@
 
 /**
  * Delete a specific live hash associated to a given account.
-
+ *
  * This transaction MUST be signed by either the key of the associated account,
  * or at least one of the keys listed in the live hash.
-
+ *
  * ### Block Stream Effects
  * None
  */

sdk/src/main/java/org/hiero/sdk/NodeCreateTransaction.java

@@ -34,14 +34,13 @@
  * - All new address book entries SHALL be added to the active network
  *   configuration during the next `freeze` transaction with the field
  *   `freeze_type` set to `PREPARE_UPGRADE`.
-
+ *
  * ### Record Stream Effects
  * Upon completion the newly assigned `node_id` SHALL be in the transaction
  * receipt.
  */
 public class NodeCreateTransaction extends Transaction<NodeCreateTransaction> {
 
-
     @Nullable
     private AccountId accountId = null;
 
@@ -261,7 +260,6 @@ public byte[] getGrpcCertificateHash() {
         return grpcCertificateHash;
     }
 
-
     /**
      * A hash of the node gRPC TLS certificate.
      * <p>
@@ -291,7 +289,6 @@ public Key getAdminKey() {
         return adminKey;
     }
 
-
     /**
      * An administrative key controlled by the node operator.
      * <p>

sdk/src/main/java/org/hiero/sdk/NodeDeleteTransaction.java

@@ -12,9 +12,9 @@
 
 /**
  * A transaction to delete a node from the network address book.
-
+ *
  * This transaction body SHALL be considered a "privileged transaction".
-
+ *
  * - A transaction MUST be signed by the governing council.
  * - Upon success, the address book entry SHALL enter a "pending delete"
  *   state.
@@ -23,7 +23,7 @@
  *   the field `freeze_type` set to `PREPARE_UPGRADE`.<br/>
  * - A deleted address book node SHALL be removed entirely from network state.
  * - A deleted address book node identifier SHALL NOT be reused.
-
+ *
  * ### Record Stream Effects
  * Upon completion the "deleted" `node_id` SHALL be in the transaction
  * receipt.

sdk/src/main/java/org/hiero/sdk/NodeUpdateTransaction.java

@@ -19,7 +19,7 @@
 
 /**
  * A transaction to modify address book node attributes.
-
+ *
  * - This transaction SHALL enable the node operator, as identified by the
  *   `admin_key`, to modify operational attributes of the node.
  * - This transaction MUST be signed by the active `admin_key` for the node.
@@ -32,7 +32,7 @@
  * - All pending node updates SHALL be applied to the active network
  *   configuration during the next `freeze` transaction with the field
  *   `freeze_type` set to `PREPARE_UPGRADE`.
-
+ *
  * ### Record Stream Effects
  * Upon completion the `node_id` for the updated entry SHALL be in the
  * transaction receipt.
@@ -342,7 +342,6 @@ public Key getAdminKey() {
         return adminKey;
     }
 
-
     /**
      * An administrative key controlled by the node operator.
      * <p>

sdk/src/main/java/org/hiero/sdk/ScheduleCreateTransaction.java

@@ -15,7 +15,7 @@
 
 /**
  * Create a new Schedule.
-
+ *
  * #### Requirements
  * This transaction SHALL create a new _schedule_ entity in network state.<br/>
  * The schedule created SHALL contain the `scheduledTransactionBody` to be
@@ -43,7 +43,7 @@
  * existing schedule and the `TransactionID` of the earlier `scheduleCreate`
  * so that the earlier schedule may be queried and/or referred to in a
  * subsequent `scheduleSign`.
-
+ *
  * #### Signature Requirements
  * A `scheduleSign` transaction SHALL be used to add additional signatures
  * to an existing schedule.<br/>
@@ -56,7 +56,7 @@
  * network consensus time reaches the schedule `expiration_time`.<br/>
  * A "short term" schedule SHALL execute immediately once signature
  * requirements are met. This MAY be immediately when created.
-
+ *
  * #### Long Term Schedules
  * A "short term" schedule SHALL have the flag `wait_for_expiry` _unset_.<br/>
  * A "long term" schedule SHALL have the flag  `wait_for_expiry` _set_.<br/>
@@ -73,14 +73,14 @@
  * A short term schedule SHALL expire, and be removed from state,
  * after the network consensus time exceeds the current network
  * configuration for `ledger.scheduleTxExpiryTimeSecs`.
-
+ *
  * > Note
  * >> Long term schedules are not (as of release 0.56.0) enabled. Any schedule
  * >> created currently MUST NOT set the `wait_for_expiry` flag.<br/>
  * >> When long term schedules are not enabled, schedules SHALL NOT be
  * >> executed at expiration, and MUST meet signature requirements strictly
  * >> before expiration to be executed.
-
+ *
  * ### Block Stream Effects
  * If the scheduled transaction is executed immediately, the transaction
  * record SHALL include a `scheduleRef` with the schedule identifier of the