Hello, reader! We’re going to go on a journey through the treacherous world of Java Class shadowing, discuss circumventing using shading, and finish with a walk through using Gradle. If you’re already familiar with the perils of Java Class shadowing feel free to skip ahead to the section on shading.
Java class shadowing
Class loaders and the classpath
A Java application runs by loading Java classes on to the JVM. Classes are loaded by class loaders. In most cases¹ your application code will be loaded by a single class loader: the System class loader. The System class loader looks up classes on the user-specified classpath². The classpath includes some combination of directories, jars, and zip files that contain class files and resources. Classes are looked up by their fully qualified name (FQN), for example org.example.foolibrary.FooClass. This is important! Since they are looked up by the FQN, if the classpath happens to have multiple classes with the same FQN, the class loader will return a single one based on the order of directories, jars, and zip files on the classpath. A common example of this is having two different versions of a library jar on the classpath; they often have classes with the same FQNs. If the classes are identical this isn’t a problem, but if they differ then any code using those classes will likely have unexpected behavior when the class loader loads up the one they weren’t expecting. …
This post contains some of the lessons I’ve learned in the past decade of growing my career. I hope they resonate with engineers of all levels, and help early to mid-level software engineers advance their careers. Some of the lessons may seem to be stating the obvious (eg “be organized”, “communicate effectively”), but spelling out exactly what they mean can provide the focus needed to make meaningful advances. Others are not as intuitive, but are instrumental in growing your skills and impact. You don’t have to be great at every one of these areas, but every little bit helps.
Don’t let code intimidate you
Documentation and collective understanding of how pieces of software work tend to be incomplete and atrophy over time. Source code, however, is always the complete and most accurate representation of a single piece of the system. Get comfortable reading code that you or anyone in your organization didn’t write — often that’s the easiest way to gain a full understanding of the module you’re working on, and it helps you understand its capabilities and constraints. A strong software engineer doesn’t shy away from digging deeper to reason about expected and observed behavior. …
Protocol buffers are a mechanism for sending data through the series of tubes known as the Internet. One common use of them is to define gRPC specifications — essentially a form of remote procedure calls. With gRPC service definitions, you create a “service” that has RPC methods. These RPC methods take a request “message” and return a response “message”.
service FooService {
rpc GetFoo (GetFooRequest) returns (GetFooResponse);
}message GetFooRequest {
string id = 1;
}message GetFooResponse {
string fooName = 1;
int64 fooValue = 2;
}
Protobuf and gRPC are powerful tools and can be used in a number of ways. What follows is a set of recommended best practices to use when defining your gRPC services using protocol buffers. …
