Requesting an upgrade of the dependency package.

[Aiden-777]

Have you considered upgrading dependencies such as gRPC?

The low version may lead to the exploitation of certain vulnerabilities that have already been exposed.

I am using a newer dependency, and issues encountered in the past have been resolved.

However, this time, the change in 'API signature' prevents me from using the latest version of gRPC in the future.

Here is the error I encountered:

*******
APPLICATION FAILED TO START
*******

Description:

An attempt was made to call a method that does not exist. The attempt was made from the following location:

    org.tron.trident.core.ApiWrapper.<init>(ApiWrapper.java:143)

The following method did not exist:

    'io.grpc.stub.AbstractStub io.grpc.stub.MetadataUtils.attachHeaders(io.grpc.stub.AbstractStub, io.grpc.Metadata)'

In the latest version of gRPC, v1.58.0:

stub: Removed deprecated methods attachHeaders and captureMetadata from MetadataUtils

[endiaoekoe]

@Aiden-777
really appreciate your reply.
the current gRPC dependencies have been introduced since trident-java project launched. but as you said above, the gRPC
APIs have evolved in the past years.
Specifically on this issue you mentioned above， the API MetadataUtils.attachHeaders are deprecated and removed from the gRPC APIs mentioned in this issue.
I think it is a good time to review the existing gRPC APIs used in trident-java project and find the ones that need to be up to date with official gRPC APIs.

[Aiden-777]

@Aiden-777 really appreciate your reply.非常感谢您的回复。 the current gRPC dependencies have been introduced since trident-java project launched. but as you said above, the gRPC当前的 gRPC 依赖项自 Trident-Java 项目启动以来就已引入。但正如你上面所说，gRPC APIs have evolved in the past years.API 在过去几年中不断发展。 Specifically on this issue you mentioned above， the API MetadataUtils.attachHeaders are deprecated and removed from the gRPC APIs mentioned in this issue.具体到您上面提到的此问题，API 已弃用并从此问题中提到的 gRPC API MetadataUtils.attachHeaders 中删除。 I think it is a good time to review the existing gRPC APIs used in trident-java project and find the ones that need to be up to date with official gRPC APIs.我认为现在是回顾三叉戟-java项目中使用的现有gRPC API并找到需要与官方gRPC API保持同步的好时机。

Looking forward to the next version upgrade. Thanks to the developers!

[jimbogithub]

+1 to resolve as these older dependencies are incompatible with newer releases of our container environment.

[endiaoekoe]

fixed in release 0.9.0

[jimbogithub]

@endiaoekoe Would you also consider switching from bcprov-jdk15on to bcprov-jdk18on? You appear to be targeting JDK 1.8 and above so bcprov-jdk18on would be better as it has many resolved CVEs versus bcprov-jdk15on. Note that it's a direct drop in as it is 'relocated': https://mvnrepository.com/artifact/org.bouncycastle/bcprov-jdk15on

[Aiden-777]

@endiaoekoe Would you also consider switching from bcprov-jdk15on to bcprov-jdk18on? You appear to be targeting JDK 1.8 and above so bcprov-jdk18on would be better as it has many resolved CVEs versus bcprov-jdk15on. Note that it's a direct drop in as it is 'relocated': https://mvnrepository.com/artifact/org.bouncycastle/bcprov-jdk15on

I've been using the bcprov-jdk18on dependency in the project all along, and it hasn't caused any side effects.

[Aiden-777]

Lately, work's been crazy busy, and I haven't had the time to dive into the latest features. I'm thinking of keeping this issue open for a while; maybe it'll spark some more coding inspiration for other developers. Like, I'm planning to use it for global rate limiting, to prevent excessive consumption of free resources when connecting to public nodes.😄

[jimbogithub]

@endiaoekoe Would you also consider switching from bcprov-jdk15on to bcprov-jdk18on? You appear to be targeting JDK 1.8 and above so bcprov-jdk18on would be better as it has many resolved CVEs versus bcprov-jdk15on. Note that it's a direct drop in as it is 'relocated': https://mvnrepository.com/artifact/org.bouncycastle/bcprov-jdk15on

I've been using the bcprov-jdk18on dependency in the project all along, and it hasn't caused any side effects.

Likewise, but it would be nice to not have to override the transitive dependency. It would be better to have this project depend on bcprov-jdk18on.