Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
I do not know when we ever need it these days. Jaunch (https://github.com/apposed/jaunch) and other smart native launchers can take care of constructing the correct system classpath for us. It was quite cool e.g. to be able to add entire folders of JARs to the classpath via the `-jarpath` option. However, the custom class loading logic has downsides, too: * Starting in Java 9, the system class loader is not necessarily a URLClassLoader anymore, which causes ClassCastException whenever we assume it is and do a hard cast. * The ClassLoaderPlus invokes Thread#setContextClassLoader() statically, meaning any time you start using it, the class loader for the current thread gets overwritten. This fact makes it hard to unit test, as evidenced by the failing test in the previous commit. I tried adding a static clear() method to ClassLoaderPlus that cleared out all the static data structures and reset the context class loader back to what it was before, but I was unable to make the test pass as part of the entire ClassLoaderPlusTest suite; only when run alone. * The custom class loading logic is significantly more complex than allowing Java's system class loader to take care of class loading via the system class path. It is a separate code path from the other ways an application might get invoked, such as from within an Integrated Development Environment (IDE), meaning some class-loading-related issues might occur only when the application is loaded and launched via the ClassLoaderPlus mechanism, but not when launched from an IDE. Therefore, to simplify the situation, I am paring back the scope of this app-launcher component to avoid use of custom class loaders in favor of only the default class loading mechanism. Obviously, this breaks backwards compatibility, so we bump to 2.x.
- Loading branch information