Yes, of course assigning a variable directly is faster than calling a method. However, there are good reasons why using a method is better.
The Uniform Access Principle says that all data of an object (or here: library) should be accessed via the same interface. This would be violated if some properties could be set directly, and others could only be set via methods. At least some properties will use methods, because of …
Validation. It may be that some config variable has the type
int, but perhaps it only accepts values
>= 0. With a
public variable, there's no way to check that. With a method, we can perform arbitrary validation.
Obviously, this does not apply to
final fields. Making constants public is no problem, except possibly for the other two reasons here. It depends on how they are used.
Encapsulation is important. If our public API consists of variables, we can never remove them without breaking backwards compatibility. This affects the inner workings of our library. When we use methods to set/get values, we can rework the internals of our library without having to change the public-facing API. For example, executing some hook when a property has been set is no problem with methods.
Together, these are three good reasons to use methods. It's just so much more flexible, and far cleaner and extensible than the alternative.
There is another issue with global variables, or more precisely with global anything: We can only have one “instance” of your library at a time. This can make testing or other advanced usage very difficult. Instead, offer your API via normal objects with the understanding that normally one would only use one instance. Using
static anything is not object-oriented, it is just thinly veiled procedural programming.
public variable is very bad,
public static method() isn't great either.
private variable is good, as is