How can I include only specific classes from a library instead of adding the entire dependency in Gradle?

If they are specific small classes (e.g. text handling), you should probably copy them.

Usually there are libraries with tons of functionality. To actually include them is up to you.

By using the library, you gain a bit more stable code, more tested, more invested, at just a simple click/include.

However, you get all of the library, which may be a lot (I'm looking at you Guava... ;) ). Not only does that increase size (and possible additional downstream dependencies which can slow down your startupspeed even more), it also adds maintenance -- will this library keep working if you upgrade your SDK, what about vulnerabilities, and it has the additional cost of possible supply chain attacks.

It used to be the case that people went 'whatever' and just included the library. These days the downsides are much more in focus and for simple functions the code is usually copied/reskinned.

The fact that you can only declare dependencies at the level of packages (JAR files) is By Design in Java. A class is seldom complete on its own and requires the presence of specific versions of other classes for a particular useful functionality to work.

On the othe hands, good designers of Java libraries do know very well to properly organise the content of a library such that it stays managable when it's declared as a dependency.

As an example of a well-designed library, please see Apache POI (notice how the different libraries are divided into components, each of which can be declared as a dependency in its own right: https://repo1.maven.org/maven2/org/apache/poi/

What you want is nonsensical.

To explain that, we first need to explain a concept.

Transitive dependencies

There's a concept known as a 'transitive dependency'. Libraries are projects and projects can have dependencies. A 'transitive dependency' is:

• A dependency of a library you use (i.e., a dependency of a dependency)...
• But your project doesn't need to know about it.

The way build systems generally work, is that they just 'take care' of it - any transitive dependencies show up in at runtime just the same, because, for the same reason your project will not work if one of your dependencies is not on the classpath when you try to run it, your dependency won't work if one of its dependencies isn't present.

The fundamental issue with your idea

A single project (such as a library you are using) is, obviously, absolutely festooned with 'dependencies within itself'. And these dependencies change all the time and aren't specced. In your own code, how often does a source file named A.java refer to anything in any other source file anywhere in the entire project? I'm guessing it's a very large number; the vast, vast majority of projects would report a very large number. Those are 'in project transitive dependencies'.

And thus, if you had what you wanted - a tool that 'strips out' anything you do not use, then the class files you do use wouldn't work because they are missing their internal dependencies.

Advanced musings: Treeshaking

In theory this is a solvable problem: Start with the code you actually need, and then have some tool 'do a scan' to automatically determine the other classes that must exist for the initial set of classes you explicitly listed out to work.

This is called 'treeshaking'.

It's not really feasible to use this unless a library has been explicitly designed to be compatible with the notion - there's service loaders and reflective loading which would frustrate a treeshaking algorithm.