From 5134eca02e4c14a9a8cb9eaf268d9a4ecb349854 Mon Sep 17 00:00:00 2001 From: Ivan Ivanov Date: Fri, 20 Dec 2024 13:12:24 +0200 Subject: [PATCH] chore: spotlessApply Signed-off-by: Ivan Ivanov --- docs/sdk/SDK_ANATOMY.md | 73 ++++++----------------------------------- tck/README.md | 10 +++++- 2 files changed, 19 insertions(+), 64 deletions(-) diff --git a/docs/sdk/SDK_ANATOMY.md b/docs/sdk/SDK_ANATOMY.md index 886591579..c2c01183d 100644 --- a/docs/sdk/SDK_ANATOMY.md +++ b/docs/sdk/SDK_ANATOMY.md @@ -32,25 +32,13 @@ Augments the Java compiler to output more comprehensive errors and warnings. Library to assist in code generation (see **FunctionalExecutableProcessor**). - - - - ## Classes: - - - - ### `LockableList`: An internal utility class that represents a list of things, and which has these capabilities: - * It can be locked, which prevents the list from being mutated. - * It has an index which can be incremented with the `advance()` method, and the index will loop back around to 0 on reaching the end of the list. - - - - +* It can be locked, which prevents the list from being mutated. +* It has an index which can be incremented with the `advance()` method, and the index will loop back around to 0 on reaching the end of the list. ### `Client`: @@ -62,10 +50,6 @@ A `Client` can be initialized from a config file (json). A `Client` can be init `executor` will be used to initialize the gRPC `BaseChannel`, and in the event that an RPC fails and needs to be retried after a delay, `executor` will be used to schedule that delayed retry. - - - - ### `BaseNode`: Has an `address`, a `channel`, an `executor` (ultimately from `Client`), `lastUsed` and `useCount`. @@ -80,10 +64,6 @@ Has an `address`, a `channel`, an `executor` (ultimately from `Client`), `lastUs The user agent is a string that is used to identify the client to the server. In this case, it's `"hiero-sdk-java/v{NUMBER}"`. - - - - ### `BaseNetwork`: This represents a network of `BaseNode`s. `Network` and `MirrorNetwork` inherit from this. @@ -96,28 +76,16 @@ Has these critical fields: `setNetwork()` will update this `Network` to the given list. It will close a `Node` and remove it from this network if it is not in the given list, and then it will then add nodes from the list. - - - - ### `Network`: This represents a network of Hedera nodes, a `Client` connects to a `Network`. `getNodeAccountIdsForExecute()` gets a list of N randomly selected `AccountId`s where N is 1/3rd (rounded up) of healthy nodes in this `Network`. This is used by `Query` and `Transaction` to populate their `nodeAccountId`s, lists containing the `AccountId`s of `Node`s that the `Query` or `Transaction` will be attempted with. - - - - ### `Node`: This is a connection to one node in the network. Inherits from `BaseNode` (which is where much of the meat is). - - - - ### `Executable`: An `Executable` object represents a request to the server. @@ -156,10 +124,6 @@ It should also be noted that the future returned by `grpc.ClientCalls.futureUnar `execute()` is simpler by virtue of not being async, but it does approximately the same thing, just without the future mumbo jumbo. - - - - ### `Query`: The `Query` class extends `Executable`. @@ -180,23 +144,19 @@ Query also adds some abstract methods of its own: `onExecute[async]()` seems to be where most of the action is in `Query`. It first makes sure that `nodeAccountIds` is filled, then it fetches the `queryPayment` amount (via `QueryCostQuery`) if one hasn't been set, then it generates the payment transactions for paying the query fee. The `paymentTransactions` list is a parallel array to `nodeAccountIds`. The `Query` proto message includes a `Transaction` proto message inside of it for paying the query fee, and `onExecuteAsync()` just goes ahead and builds a parallel array of `Transaction` messages which are to be used in the event that we attempt to send our query to that node. - - - - ### `Transaction`: The `Transaction` class extends `Executable`. A transaction is used like this: - - Instantiate a subclass of `Transaction`. - - Call methods to configure it. - - OPTIONAL: - - Freeze the transaction. - - Add more signatures. - - Execute the transaction (it will be frozen if not already frozen, and will be signed with client operator). - - `execute()` returns (or in the case of `executeAsync()`, returns in future) a `TransactionResponse`. - - OPTIONAL: use the resulting `TransactionResponse` to get the `TransactionReceipt` for free, or pay a fee to get the `TransactionRecord`. Fetching either of these is itself a query. +- Instantiate a subclass of `Transaction`. +- Call methods to configure it. +- OPTIONAL: +- Freeze the transaction. +- Add more signatures. +- Execute the transaction (it will be frozen if not already frozen, and will be signed with client operator). +- `execute()` returns (or in the case of `executeAsync()`, returns in future) a `TransactionResponse`. +- OPTIONAL: use the resulting `TransactionResponse` to get the `TransactionReceipt` for free, or pay a fee to get the `TransactionRecord`. Fetching either of these is itself a query. The `Transaction` class is greatly complicated by three factors: @@ -309,10 +269,6 @@ The `Transaction` is not immediately sent after freezing. Instead, the user of `validateChecksums()` has the same function as in `Query` - - - - ### `TopicMessageQuery` Unlike most classes in the Hedera SDK, this is _not_ a query to a Hedera Hashgraph network, it is a query to a _mirror_ network. As such, it is _not_ a subclass of `Query`, despite its name. @@ -325,10 +281,6 @@ The responses may be chunked. If they are, `TopicMessageQuery` will collect all In addition to the `onNext()` handler, there are several optional handlers which can be set with `setCompletionHandler()`, `setErrorhandler()`, and `setRetryHandler()`. The retry handler returns a boolean to indicate whether the query should be retried. - - - - ### `FunctionalExecutable` and `FunctionalExecutableProcessor` These classes aren't themselves components of the SDK, they are components in the SDK's build process. `FunctionalExecutable` is a custom annotation defined in the `executable-annotation` directory, and we use this annotation is in the SDK source code to mark methods that require additional processing during the build process. This additional processing is performed by the `FunctionalExecutableProcessor`, which is defined in the `executable-processor` directory. @@ -350,9 +302,4 @@ The `FunctionalAnnotationProcessor` can't add these methods to `Bar` directly. If you want to get a better grasp on what the `FunctionalExecutableProcessor` actually does, I suggest that after building the SDK, you should look at the files in `sdk/build/generated/sources/annotationProcessor/java/main/org/hiero/sdk/`. These are the `With*.java` files that are generated by the `FunctionalExecutableProcessor` during the build process. For example, the `WithExecute.java` file was generated because of the `@FunctionalExecutable` annotation on the `Executable.executeAsync()` method, and if you look at `WithExecute.java` side-by-side with the `FunctionalExecutableProcessor.process()` method body, you should be able to see how each of the default methods in the `WithExecute` interface were generated by the processor - - - - **This document is not comprehensive. There are classes I have not yet documented, or which I have only documented in passing, like `ChunkedTransaction`.** - diff --git a/tck/README.md b/tck/README.md index 0d5d96ab2..9b6095ed4 100644 --- a/tck/README.md +++ b/tck/README.md @@ -1,24 +1,32 @@ # Java SDK TCK Server ## Description + This module contains implementation of the JSON-RPC server for the Java SDK to interpret and process requests from the Test Driver based on the [TCK's](https://github.com/hiero-ledger/hiero-sdk-tck) requirements. Upon receiving a request, it executes the corresponding function or procedure associated with the method specified in the request. Subsequently, it prepares the response in JSON format and sends it back to the test driver. ## Setup + **1. Navigate into tck directory.** + ```shell cd tck ``` + **2. Build the project using Gradle.** + ```shell ./gradlew build ``` + **3. Run the server.** + ```shell ./gradlew bootRun ``` By default, the server will occupy port 80. If you need to specify a different port, modify the port in the `application.yml` file: -``` yaml + +```yaml server: port: ```