Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

modernize jdk level and dependencies #496

Open
sreuland opened this issue Jul 27, 2023 · 5 comments
Open

modernize jdk level and dependencies #496

sreuland opened this issue Jul 27, 2023 · 5 comments

Comments

@sreuland
Copy link
Contributor

sreuland commented Jul 27, 2023

What problem does your feature solve?

jdk is pinned to LTS 1.8 from 2014 version.
uses some library deps that were prior required due to gaps in older jdk's such as threeten for date/time and to some degree google guava and okhttpclient.

What would you like to see?

upgrade the jdk to LTS 11 which came out in 2018.

evaluate using builtin java.net.HTTPClient and removing dep on okhttpclient which pulls in entire Kotlin library for not much value-add

  • use as opportunity for refactor to streamline org.stellar.sdk.Server, don't expose internal http client aspect
    • replace current constructors with a org.stellar.sdk.ServerBuilder with required param setterwithServerURL, and optionals forwithTimeout, withTxSubmitTimeout
    • remove getter/setters for internal http client

use jdk built-in java.time.* instead of threeten dep

What alternatives are there?

@Ifropc
Copy link
Contributor

Ifropc commented Aug 3, 2023

FYI: removing deps on okhttpclient will break existing users who provide their own instance of okhttpclient in order to customize client (i.e. timeouts, etc)

@sreuland
Copy link
Contributor Author

sreuland commented Aug 3, 2023

FYI: removing deps on okhttpclient will break existing users who provide their own instance of okhttpclient in order to customize client (i.e. timeouts, etc)

yes, thanks for pointing out, would be breaking change for org.stellar.sdk.Server since it exposes the http client internals like that with constructors and getter/setters. I updated details on description to include that scope for consideration.

@overcat
Copy link
Member

overcat commented Sep 11, 2023

Can we consider removing the guava dependency? After upgrading to version 1.8+, most of the functionalities we use in guava have alternatives in the standard library, except for ImmutableList, but is it worth introducing it just for ImmutableList?

@sreuland
Copy link
Contributor Author

Can we consider removing the guava dependency? After upgrading to version 1.8+, most of the functionalities we use in guava have alternatives in the standard library, except for ImmutableList, but is it worth introducing it just for ImmutableList?

yes, I think your current pr could be one place to try or we create another tech debt ticket specific to guava removal as it touches alot of files.

https://github.com/stellar/java-stellar-sdk/pull/523/files/2555cfebc54ac8428d4c3319902929ebf7277356..2d0561a5f7f1df27386b1dbb0fcf640235d6c449

@overcat
Copy link
Member

overcat commented Oct 30, 2023

Currently, java.net.HTTPClient cannot be used on the Android platform(source). Of course, we can design the http client as an interface and provide services through java.net.HTTPClient in this SDK, and then use OkHttpClient to provide services on the Android platform through SPI.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants
@overcat @sreuland @Ifropc and others