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
State is accumulating unnecessarily in AST tranformation instances.
We can fix the ones we have implemented so far just by using a
local variable and passing it into the methods where it is used.
All the methods are private so this change is safe in a point release.
Fixes gh-5283
When an application is run as an executable archive with nested jars,
the application's own classes need to be able to load classes from
within the nested jars. This means that the application's classes need
to be loaded by the same class loader as is used for the nested jars.
When an application is launched with java -jar the contents of the
jar are on the class path of the app class loader, which is the
parent of the LaunchedURLClassLoader that is used to load classes
from within the nested jars. If the root of the jar includes the
application's classes, they would be loaded by the app class loader
and, therefore, would not be able to load classes from within the
nested jars.
Previously, this problem was resolved by LaunchedURLClassLoader being
created with a copy of all of the app class laoder's URLs and by
using an unconventional delegation model that caused it to skip its
parent (the app class loader) and jump straight to its root class
loader. This ensured that the LaunchedURLClassLoader would load both
the application's own classes and those from within any nested jars.
Unfortunately, this unusual delegation model has proved to be
problematic. We have seen and worked around some problems with Java
Agents (see gh-4911 and gh-863), but there are others (see gh-4868)
that cannot be made to work with the current delegation model.
This commit reworks LaunchedURLClassLoader to use a conventional
delegate model with the app class loader as its parent. With this
change in place, the application's own classes need to be hidden
from the app class loader via some other means. This is now achieved
by packaging application classes in BOOT-INF/classes (and, for
symmetry, nested jars are now packaged in BOOT-INF/lib). Both the
JarLauncher and the PropertiesLauncher (which supports the executable
jar layout) have been updated to look for classes and nested jars in
these new locations.
Closes gh-4897
Fixes gh-4868
It seems that the code for executing a groovy closure from the
OptionHandler is never executed and therefore not needed.
Removing the code gives the benefit that the Groovy-classes are not
needed if someone else wants to use the spring-boot-cli infrastructure to
run his own cli interface.
Closes gh-4411
Previously, MavenSettings used a FileProfileActivator with no
PathTransformer. If a settings.xml file contains a file-activated
profile this would result in an NPE within Maven. This was made worse
by the NPE not being included in the resulting failure message which
hampered diagnosis of the problem.
This commit updates MavenSettings to configure its FileProfileActivator
with a PathTransformer. It also improves the failure message that’s
created from any problems that are reported by Maven while determining
the active profiles to include a problem’s exception if it has one.
Closes gh-4826
Ensure that Collections.isEmpty() is used to check if there are no
elements in a collections. This is more explicit and can be faster than
calling .size().
Closes gh-4783
The CLI application advertises `-cp` support but it appears that only
`--cp` is really supported. The fix for gh-178 forgot to update the
call to `getParser().parse(...)`.
See gh-178
Spring Initalizr now bundles a wrapper script for the build system. While
that wrapper has the necessary execute flag in the zip archive, that flag
is lost as the zip abstraction does not honor those.
The init command now makes sure to restore the execute flag on `mvnw`
and `gradlew` if necessary.
Unfortunately, this can't be tested as the Windows build would fail to
assert that the executable flag has been propertly set.
Closes gh-4392
Plugin authors can extend this class, provide missing methods,
and specify a BOM to add to the dependency management lookup
(i.e. dependencies by artifactId)
Certain Maven profile activator’s require access to System properties
to determine whether or not a profile should be activated.
JdkVersionProfileActivator is one such activator.
Prior to this commit, the presence of a Maven profile that was activated
based on the JDK in a bom imported using @DependencyManagementBom in the
CLI would trigger a failure as the JdkVersionProfileActivator could not
determine the version of Java on which it was running.
This commit updates the CLI to pass the JVM’s System properties to the
request to build a bom’s model so that those system properties can be
used by JdkVersionProfileActivator (and any other activators which need
them).
Andy Wilkinson
Phillip Webb
Johnny Lim
Jakub Narloch
Dave Syer
Stephane Nicoll
Johannes Edmeier
mnhock
Kirill Vlasov
Matt Benson
Andrey Stolyarov