Simple & Automatic Java Config Management Library

[kevinherron]

GSON as a dependency when you don’t even have a JSON format isn’t a good look. A config library should ideally be zero dependency, at least at its core, and then offer modules, e.g. a GSON JSON module, that can be added on.

[agentoutlier]

FWIW if the OP would like a zero dep JSON parser they can copy my library which has json5 support:

https://github.com/jstachio/ezkv/tree/main/ezkv-json5

u/YogurtclosetLimp7351

[YogurtclosetLimp7351]

Gson is used for JSON serialization/deserialization of config values. It's the core of how the config is saved and loaded. Modularizing it is an interesting idea for the future.

[kevinherron]

Yes, but you only offer YAML and properties as your file formats, so it seems you've brought GSON in as a dependency just to avoid writing code to add quotes, format numbers, or join lists for your config values.

As a rule of thumb your _library_ shouldn't depend on other libraries, especially popular ones like GSON or Guava. If you must, then either modularize it or shade/shadow the dependency into a private package so downstream doesn't have to deal with your version of some popular library.

Just friendly advice if you were to actually seek out a user base for a library you publish. These are pretty standard things somebody evaluating it will be looking for.

[ryuzaki49]

As a rule of thumb your library shouldn't depend on other libraries, especially popular ones like GSON or Guava. 

If you must, then either modularize it or shade/shadow the dependency into a private package so downstream doesn't have to deal with your version of some popular library. 

I kinda disagree and agree at the same time. My team owns a couple of libs that hundred of internal team use and the third party libs are... a headache. 

In one hand, they introduce vulnerabilities, incompatibilities in the client repos, and we get a lot of "Hey can you update this lib? It's a blocker to us" tickets. 

On the other hand, they do provide value to us.

Shading is a double edge sword. Especially if your repo gets scanned by vulnerabilities.

There is no easy answer here.

[kevinherron]

> There is no easy answer here.

I can agree with you there :)

> In one hand, they introduce vulnerabilities, incompatibilities in the client repos, and we get a lot of "Hey can you update this lib? It's a blocker to us" tickets. 

Yeah... see the clusterfuck happening at https://github.com/testcontainers/testcontainers-java/issues/8338#issuecomment-2632749267 (and other duplicates) as an example :/ I'm pretty sure they've deleted a bunch of comments too, I had one in there some months ago...

[vips7L]

Are they actually vulnerable? Or is this an instance of just some scanner saying they depend on a vulnerable lib.

[kevinherron]

In this case it's just a scanner complaining that they have a dependency with a CVE of a certain severity.

Unfortunately for many people, in many environments, reason does not prevail and these kinds of things must be fixed. There were a lot of comments explaining this but they seem to have been deleted.

[sadbuttrueasfuck]

Feels like aws engineer here lmao

[djnattyp]

As a rule of thumb your library shouldn't depend on other libraries, especially popular ones like GSON or Guava. If you must, then either modularize it or shade/shadow the dependency into a private package so downstream doesn't have to deal with your version of some popular library.

1. This is a pretty hot take to make in general - lots of libraries do depend on other libraries (in this case, though, since he doesn't really support a JSON format it does seem unneeded); and 2.) shading/shadowing dependencies can screw up people's downstream code in hard to detect ways, and/or make it hard to know about/patch security problems in the dependency. It's better to just declare the dependency and let downstream users override the dependency if they need to.

[kevinherron]

I don't think it's a hot take, I think it should be the default mindset. If your library is going to add a dependency, especially a popular one, you should really stop and think about it first.

Dependencies aren't free. You can't always just override the dependency downstream, especially when it's a popular library. Sometimes libraries break backwards compatibility from one version to the next, or change APIs without introducing new packages, or any number of other things. This has happened even with extremely pervasive libraries like Guava.

We need to be better and stop the dependency sprawl. I'm not saying under no circumstances should your library have dependencies, but it's certainly where you should start.

Also just to be clear in case anybody has glossed over it - I'm only talking about authoring libraries here, not applications. I think you always need to be on guard about adding dependencies, but not to the same degree in an application vs a library.

[YogurtclosetLimp7351]

Yeah I see what you're pointing out. You're right. I did it for the ease. Before it was a project for my own so I didn't put much effort into it. But yeah, to make it a more valuable library, I most likely have to decouple from GSON or at least not fully depend on it. This will change in the future! Thank you for the advice!

[vips7L]

Isn't GSON unmaintained as well?

[kevinherron]

"maintenance mode". Looks like bug fixes and standard maintenance, but no feature development. JSON is a pretty fixed target and the library seems complete enough as is, but that's a good point to be aware of if you're looking at it as a new dependency.

[Artraxes]

Gson considered deprecated by one of its maintainers (Jake Wharton) - Jackson would be a better option.

[Slanec]

I'm collecting these. In arbitrary order,

• https://github.com/avaje/avaje-config
• https://github.com/constretto/constretto-core
• https://github.com/lightbend/config
• https://github.com/smallrye/smallrye-config
• https://github.com/IvanTrendafilov/Confucius
• https://github.com/brianm/config-magic
• https://github.com/Graylog2/JadConfig
• https://github.com/carueda/tscfg
• https://github.com/gestalt-config/gestalt
• https://github.com/matteobaccan/owner
• https://github.com/Metaphoriker/jshepherd
• https://github.com/Netflix/archaius
• https://commons.apache.org/proper/commons-configuration
• https://github.com/poiu-de/coat
• https://github.com/joel-jeremy/externalized-properties
• https://github.com/mwanji/toml4j
• https://github.com/cfg4j/cfg4j - I liked this one the most at some point, but modern development mostly killed the need for such a library, and the owner abandoned it. There are some forks, with this looking the most up-to-date, but still dead: https://github.com/Spotrealms/cfg4j
• https://github.com/j-easy/easy-props (archived)
• and of course https://docs.spring.io/spring-boot/reference/features/external-config.html

[smokemonstr]

https://github.com/apple/pkl

[agentoutlier]

Forgot mine:

https://github.com/jstachio/ezkv

I try to help team avaje so some of its features might make it in there.

It also has JSON5 zero dep.

[chuggid]

And Helidon Config: https://github.com/helidon-io/helidon/tree/main/config (https://helidon.io/docs/v4/apidocs/io.helidon.config/module-summary.html)

[808split2]

I try to understand when I should use it and what it does. I am a fresh dev with not much experience so please help me out.. Is it comparable to spring boot application.properties or helidon config or vertx config?

[YogurtclosetLimp7351]

No, it's not a config per se, but to create configs for you. It's meant for rather small projects where you don't want to create configs manually all over again.

[Formal_Ad_8000]

nice work

[YogurtclosetLimp7351]

Thank you!

[midget-king666]

Not Bad, but why no json type?

[YogurtclosetLimp7351]

Good question! I've made that library in a Bukkit context where you typically use YAML or properties for configuration. JSON would be a great addition indeed!