- rearrange compile call parameters for clarity, more defaults
- remove baseConfiguration method - it is now covered by defaultConfiguration
for static part, and refineConfiguration call if a config parameter is
specified
- implement proper configurations chaining, documented in comment to compile function
- minor renamings and refactorings
- flatten the structure
- add some parameters
- replace iterables with lists
- renaming all scope objects uniformily
also:
- fix passing and usage of script sources
- renamings and other minor improvements
- get rid of selector (because of confusions), move it's data into
definition itself and make it more generic with heterogeneous map
- make main KotlinScript annotation accept complete definition
- make additional annotation for building definition from parts
- add ScriptingEnvironment and pass it as a constructor parameter to
the script handlers
- rename some classes for clarity
The standard way of loading resources with built-ins metadata from the
current class loader no longer works in the modular mode on Java 9
because the current class loader is for module 'kotlin.reflect', but the
metadata is located in the module 'kotlin.stdlib'. On Java 9, we now use
the class loader of 'kotlin.stdlib' to load these resources.
#KT-21266 Fixed
Using the new multi-release jar feature, store compiled
module-info.class files into META-INF/versions/9 instead of the artifact
root. Hopefully, this will break fewer tools which do not support
module-info.class files because any sane tool should not do anything
with files in META-INF because before Java 9 that directory only
contained resources.
Upgrade some Maven plugins to newer versions which do not fail on
module-info.class files
#KT-21266 In Progress
This fixes the "Some JAR files in the classpath have the Kotlin Runtime
library bundled into them" warning when compiling all modules that
depend on kotlin-reflect-api. This warning is reported on jars in the
classpath which look like standard library artifacts, but in fact are
not because their manifest does not say so. With this change, we're now
writing the manifest of standard library artifacts to the resulting jar
of kotlin-reflect-api, with the standard library component name
"internal" (in fact, it doesn't affect anything here, any name would be
OK) to make the compiler believe that this is actually a standard
library jar
Avoid creating new `BigDecimal` instance by calling `BigDecimal.valueOf(this)`, which doesn't create a new instance if the argument falls in the range [0..10].
(there's a `private static final BigDecimal[] zeroThroughTen` cache in BigDecimal.java with 11 BigDecimal instances)
Vyacheslav Gerasimov