This works, and feels like the right thing to do, since there is no
guarantee that extensions won't in turn use ServiceLoader for things
that we haven't yet anticipated.
Fixes gh-6829. Cc @wilkinsona in case he has an opinion.
Previously, CLI extensions where installed into the CLI's lib
directory which meant that they were on the class path of the app
class loader. Following the change to an executable jar's packaging,
this meant that they could not see classes in the CLI and a
ClassNotFoundException would result.
This commit updates the CLI to install extensions into lib/ext and
load commands using a new ClassLoader that has all of the jars in
lib/ext on its class path and that uses the launch class loader as
its parent.
Closes gh-6615
Where possible, code that previously synchronized on this (or on the
class in the case of static methods) has been updated to use an
internal monitor object instead. This allows the locking model that's
employed to be an implementation detail rather than part of the
class's API.
Classes that override a synchronized method continue to declare
the overriding method as synchronized. This ensures that locking
is consistent across the superclass and its subclass.
Closes gh-6262
Previously, the CLI would always use the class loader to try to locate
a source file. This was contrary to the SourceOptions javadoc which
states that the class loader is “used to try and load files that are
not found in the local filesystem”. This provide to be problematic on
Windows when a fully-qualified source file was supplied. The driver
letter colon slash (e.g. c:/) at the start of the path is considered
invalid for a class path resource by URLClassPath.Loader resulting in an
IllegalArgumentException being thrown.
A workaround for this URLClassPath behaviour was added in a71c9b5d. It
was removed as part of reworking LaunchedURLClassLoader to use a
conventional delegation model in 87fe0b2a. It was then reinstated in
cc140b2c. This work around is undesirable as it causes
LaunchedURLClassLoader’s behaviour to diverge from URLClassLoader’s
behaviour (this is contrary to the comments in the test added in
a71c9b5d which incorrectly tests the two class loader with different
class paths. If the two class loaders are created with the same class
path then their behaviour is the same).
This commit updates SourceOptions to make its behaviour match its
javadoc so that a search of the class path is only performed if the
filename doesn’t exist on the filesystem. Furthermore, when running on
Windows, if the filename is an absolute path no further searching is
performed as the path cannot reliably be used to search the class path
due to the behaviour of URLClassPath.Loader when given a path that
is an absolute file path on Windows. This ensures that the user is
presented with an error message indicating that the file could not be
found.
Closes gh-5650
Dave Syer
Phillip Webb
Stephane Nicoll
Henri Kerola
Andy Wilkinson
Spring Buildmaster
Johnny Lim
nagarajasr
Vedran Pavic
Jakub Narloch