Application does not have to be rewritten unlike the migration when upgrading a framework. There are several comparisons that can still be made between the transition when upgrading the sdk versus upgrading the framework. These are described via the change of APIs in either case. The set of deprecated API is usually more for an application that is tightly bound to a framework with a larger number of breaking changes. There are no such requirements for sdk which usually has little breaking changes in the API. On the other hand, the effort to publish multiple jars is somewhat more convenient to maintain backward compatibility.
File structure layout for the code does not have to. Hange with the upgrade of the jdk bbut the same cannot be said to be true for the migration or upgrade of framework.
Finally. Build tools help a lot with the preparation for an upgrade of jdk. Gradle has a number of plugins which are determined at the outset and very early before the compilation of the code.
Gradle can optimize the loading and re-use of plugin classes, allow different plugins for different versions of classes and provide editors which detail information about the potential properties and values in the buildscript.
The plugins can also be extracted during compilation rather than require pre-installation. It might look like the traditional apply() method in gradle is no different from the plugins block and that they both serve to list plugins and their versions but the latter is actually more recent, has more rigorous checks, constraints and restrictions. If we want to avoid the restrictions, we could make use of the buildScript block. Gradle has support for multi-project builds so the build.gradle is composable for different projects
No comments:
Post a Comment