Potential conflicts with `config.properties` being in the classpath root

[wheata03]

bitmovin-java/src/main/java/com/bitmovin/api/BitmovinApi.java

Line 171 in fbdeffc

InputStream inputStream = BitmovinApi.class.getClassLoader().getResourceAsStream("config.properties");

config.properties is quite a generic name to exist in the root of the classpath.

Unfortunately, the standard classloader, when getResourceAsStream is called, will search the classpath root, and adjacent to the class [0]. Empirical evidence [see test case below] suggests that it looks next to the class first e.g. with the class and package being com.bitmovin.api.BitmovinApi it will look for /com/bitmovin/api/config.properties before it looks for /config.properties

The standard classloader will also return the first config.properties it finds on the classpath, If the application's classpath happens to have another dependency that also has config.properties in the root of the classpath, and the other dependency appears first in the classloader, then the Bitmovin version will be ignored.

Given the above, I recommend that /com/bitmovin/api/config.properties be used in preference.

[0] https://javachannel.org/posts/how-to-access-static-resources/

Sample Testcase:

// src/main/java/com/example/gras/Main.java
package com.example.gras;

import java.io.InputStream;
import java.util.Properties;

public class Main {
    public static void main(String[] args) throws Exception {
        InputStream in = Main.class.getResourceAsStream("tmp.properties");
        Properties p = new Properties();
        p.load(in);
        System.out.println("Foo property: " + p.getProperty("Foo"));
    }
}

# src/main/resources/tmp.properties
Foo=root

# src/main/resources/com/example/gras/tmp.properties
Foo=dir