Expand Authors Top

If you have a few years of experience in the Java ecosystem and you’d like to share that with the community, have a look at our Contribution Guidelines.

November Discount Launch 2022 – Top
We’re finally running a Black Friday launch. All Courses are 30% off until next Friday:

>> GET ACCESS NOW

November Discount Launch 2022 – TEMP TOP (NPI)
We’re finally running a Black Friday launch. All Courses are 30% off until next Friday:

>> GET ACCESS NOW

Expanded Audience – Frontegg – Security (partner)
announcement - icon User management is very complex, when implemented properly. No surprise here.

Not having to roll all of that out manually, but instead integrating a mature, fully-fledged solution - yeah, that makes a lot of sense.
That's basically what Frontegg is - User Management for your application. It's focused on making your app scalable, secure and enjoyable for your users.
From signup to authentication, it supports simple scenarios all the way to complex and custom application logic.

Have a look:

>> Elegant User Management, Tailor-made for B2B SaaS

1. Overview

JAR files are Java archives. We may include various JAR files as libraries when we build Java applications.

In this tutorial, we'll explore how to find the JAR file and its full path from a given class.

2. Introduction to the Problem

Let's say we have a Class object at runtime. Our goal is to find out which JAR file the class belongs to.

An example may help us understand the problem quickly. Let's say we have the class instance of Guava‘s Ascii class. We want to create a method to find out the full path of the JAR file that holds the Ascii class.

We'll mainly address two different methods to get the JAR file's full path. Further, we'll discuss their pros and cons.

For simplicity, we'll verify the result by unit test assertions.

Next, let's see them in action.

3. Using the getProtectionDomain() Method

Java's class object provides the getProtectionDomain() method to obtain the ProtectionDomain object. Then, we can get the CodeSource through the ProtectionDomain object. The CodeSource instance will be the JAR file we're looking for. Further, CodeSource.getLocation() method gives us the URL object of the JAR file. Finally, we can use the Paths class to get the full path of the JAR file.

3.1. Implementing the byGetProtectionDomain() Method

If we wrap all steps that we've mentioned above in a method, a couple of lines will do the job:

public class JarFilePathResolver {
    String byGetProtectionDomain(Class clazz) throws URISyntaxException {
        URL url = clazz.getProtectionDomain().getCodeSource().getLocation();
        return Paths.get(url.toURI()).toString();
    }
}

Next, let's take the Guava Ascii class as an example to test if our method works as expected:

String jarPath = jarFilePathResolver.byGetProtectionDomain(Ascii.class);
assertThat(jarPath).endsWith(".jar").contains("guava");
assertThat(new File(jarPath)).exists();

As we can see, we've verified the returned jarPath through two assertions:

  • first, the path should point to the Guava JAR file
  • if jarPath is a valid full path, we can create a File object from jarPath, and the file should exist

If we run the test, it passes. So the byGetProtectionDomain() method works as expected.

3.2. Some Limitations of the getProtectionDomain() Method

As the code above shows, our byGetProtectionDomain() method is pretty compact and straightforward. However, if we read the JavaDoc of the getProtectionDomain() method, it says the getProtectionDomain() method may throw SecurityException.

We've written a unit test, and the test passes. This is because we're testing the method in our local development environment. In our example, the Guava JAR is located in our local Maven repository. Therefore, no SecurityException was raised.

However, some platforms, for instance, Java/OpenWebStart and some application servers, may prohibit getting the ProtectionDomain object by calling the getProtectionDomain() method. Therefore, if we deploy our application to those platforms, our method will fail and throw SecurityException.

Next, let's see another approach to get the JAR file's full path.

4. Using the getResource() Method

We know that we call the Class.getResource() method to get the URL object of the resource of the class. So let's start with this method to resolve the full path of the corresponding JAR file finally.

4.1. Implementing the byGetResource() Method

Let's first have a look at the implementation and then understand how it works:

String byGetResource(Class clazz) {
    URL classResource = clazz.getResource(clazz.getSimpleName() + ".class");
    if (classResource == null) {
        throw new RuntimeException("class resource is null");
    }
    String url = classResource.toString();
    if (url.startsWith("jar:file:")) {
        // extract 'file:......jarName.jar' part from the url string
        String path = url.replaceAll("^jar:(file:.*[.]jar)!/.*", "$1");
        try {
            return Paths.get(new URL(path).toURI()).toString();
        } catch (Exception e) {
            throw new RuntimeException("Invalid Jar File URL String");
        }
    }
    throw new RuntimeException("Invalid Jar File URL String");
}

Compared to the byGetProtectionDomain approach, the method above looks complex. But in fact, it's pretty easy to understand as well.

Next, let's walk through the method quickly and understand how it works. For simplicity, we throw RuntimeException for various exception cases.

4.2. Understanding How It Works

First, we call the Class.getResource(className) method to get the URL of the given class.

If the class is from a JAR file on the local filesystem, the URL string should be in this format:

jar:file:/FULL/PATH/TO/jarName.jar!/PACKAGE/HIERARCHY/TO/CLASS/className.class

For example, here's the URL string of Guava's Ascii class on a Linux system:

jar:file:/home/kent/.m2/repository/com/google/guava/guava/31.0.1-jre/guava-31.0.1-jre.jar!/com/google/common/base/Ascii.class

As we can see, the full path of the JAR file lies in the middle of the URL string.

As the file URL format on different operating systems may differ, we'll extract the “file:…..jar” part, convert it back to a URL object, and use the Paths class to get the path as a String.

We build a regex and use String‘s replaceAll() method to extract the part we need: String path = url.replaceAll(“^jar:(file:.*[.]jar)!/.*”, “$1”);

Next, similar to the byGetProtectionDomain() approach, we get the final result using the Paths class.

Now, let's create a test to verify if our method works with Guava's Ascii class:

String jarPath = jarFilePathResolver.byGetResource(Ascii.class);
assertThat(jarPath).endsWith(".jar").contains("guava");
assertThat(new File(jarPath)).exists();

The test will pass if we give it a run.

5. Combining the Two Methods

So far, we've seen two approaches to solve the problem. The byGetProtectionDomain approach is straightforward and reliable, but may fail on some platforms due to security limitations.

On the other hand, the byGetResource method doesn't have security issues. However, we need to do more manual manipulations, such as handling different exception cases and extracting the URL string of the JAR file using regex.

5.1. Implementing the getJarFilePath() Method

We can combine the two methods. First, let's try to resolve the JAR file's path with byGetProtectionDomain(). If it fails, we call the byGetResource() method as a fallback:

String getJarFilePath(Class clazz) {
    try {
        return byGetProtectionDomain(clazz);
    } catch (Exception e) {
        // cannot get jar file path using byGetProtectionDomain
        // Exception handling omitted
    }
    return byGetResource(clazz);
}

5.2. Testing the getJarFilePath() Method

To simulate byGetProtectionDomain() throwing SecurityException in our local development environment, let's add Mockito dependency and partially mock the JarFilePathResolver using the @Spy annotation:

@ExtendWith(MockitoExtension.class)
class JarFilePathResolverUnitTest {
    @Spy
    JarFilePathResolver jarFilePathResolver;
    ...
}

Next, let's first test the scenario that the getProtectionDomain() method doesn't throw a SecurityException:

String jarPath = jarFilePathResolver.getJarFilePath(Ascii.class);
assertThat(jarPath).endsWith(".jar").contains("guava");
assertThat(new File(jarPath)).exists();
verify(jarFilePathResolver, times(1)).byGetProtectionDomain(Ascii.class);
verify(jarFilePathResolver, never()).byGetResource(Ascii.class);

As the code above shows, apart from testing whether the path is valid, we also verify that if we can get the JAR file's path by the byGetProtectionDomain() method, the byGetResource() method should never be called.

Of course, if byGetProtectionDomain() throws SecurityException, the two methods will be called once:

when(jarFilePathResolver.byGetProtectionDomain(Ascii.class)).thenThrow(new SecurityException("not allowed"));
String jarPath = jarFilePathResolver.getJarFilePath(Ascii.class);
assertThat(jarPath).endsWith(".jar").contains("guava");
assertThat(new File(jarPath)).exists();
verify(jarFilePathResolver, times(1)).byGetProtectionDomain(Ascii.class);
verify(jarFilePathResolver, times(1)).byGetResource(Ascii.class);

If we execute the tests, both tests pass.

6. Conclusion

In this article, we've learned how to get a JAR file's full path from a given class.

As always, the complete source code is available over on GitHub.

November Discount Launch 2022 – Bottom
We’re finally running a Black Friday launch. All Courses are 30% off until next Friday:

>> GET ACCESS NOW

Generic footer banner
Comments are closed on this article!