Evaluating this project ...

[hrstoyanov]

Hi all,
I am evaluating this library and have a few questions:

1. Are there any particularly strong reasons for using Lombok?
   One can use Java records instead of @Value classes, Interfaces with static methods for utility classes, Java Checker Framework for null checks, and a few hand-written builders.
2. Have you considered using Java 9+ System.Logger instead of SL4J - it does the same job.
3. Have you considered modularize this library (as in Java 9 modules)
4. Have you considered removing Google Guava - not really needed for modern java anymore.
5. Have you considered removing Apache HttpCient and use Java 11+ native http client instead.

I am willing to help with any of the above.

For a library like this, it is very important to bring in minimal dependencies, be very portable (including compilation with Graal)

[emlun]

Hi!

(1) - Lombok helps eliminate boilerplate code that's mostly noise, which leaves fewer coupled code sections that could go out of sync. For example, this makes it impossible to forget to update (or regenerate) equals() and hashCode() when changing data structures. Also, most of the classes use builders for construction, so having most of that auto-generated is a big help.

(2) and (3) - We support all LTS releases of Java, which still includes Java 8, so we cannot use features that require newer Java versions at runtime. We recently added an Automatic-Module-Name header for better forward-compatibility with JPMS, but as noted in #276 (comment) we cannot fully modularize the application yet.

(4) - I've tried toward that occasionally and made some progress, but it hasn't as of yet been a priority. The main thing that remains is a couple of calls to com.google.common.net.InetAddresses.isInetAddress() in the AppId class, used for the appid extension.

(5) - Note that HttpClient is not used to make HTTP requests, it is only used in the android-safetynet attestation statement verifier to verify the hostname of an X.509 certificate. This could probably be eliminated as well.

Does that answer your questions?

[hrstoyanov]

(1) - (3)
Ok, I see, so you want to stay Java 8 compatible (Lombok makes sense for old java 8, but is vastly unnecessary with Java 17+ records, etc)

(4)
I remember Guava being such a pain as different libs would require different versions (jar hell) . But sticking to it for such minor reason is a problem (for me anyway). Maybe you can just copy over only the bits you need from it, and let it go?

(5) I agree with you this can be dropped easily, apache http client brings a lot of unnecessary apache dependencies by itself.

I would highly encourage you to consider upgrading to Java 17 perhaps in a new major version, take full advantage of it (but maybe also maintain a "prior bug-fix-only" version that is going to see point releases and remain Java 8 compatible)

Thanks for your time!

[emlun]

Maybe you can just copy over only the bits you need from [Guava and Apache httpclient], and let it go?

Probably, yeah. We don't have this work planned at the moment, but do you have a particular preferred timeline in mind?

[hrstoyanov]

No rush from me, I am just shopping around for a simple WebAuthn lib for a Helidon web app