## Simplify ScriptConfigurationManager mental model Everything related to cache managing moved to `org.jetbrains.kotlin.idea.core.script.configuration`. DefaultScriptConfigurationManager slitted into: - `AbstractScriptConfigurationManager` - `DefaultScriptConfigurationManager` - `ScriptClassRootsCache` The main idea is to simplify the mental model of ScriptConfigurationManager. Concrete implementation should provide just two things: - `createCache(): ScriptConfigurationCache` that should return cache implementation with `get` and `set` methods - `reloadOutOfDateConfiguration(...)` will be called on [cache] miss or when [file] is changed. Implementation should initiate loading of [file]'s script configuration and call [saveChangedConfiguration] immediately or in some future (e.g. after user will click "apply context" or/and configuration will be calculated by some background thread). Everything around it is implemented in `AbstractScriptConfigurationManager`. `ScriptClassRootsCache` is extracted from `DefaultScriptConfigurationManager`: this simplifies `AbstractScriptConfigurationManager` Also it simplifies ScriptClassRootsCache reset: we can just drop old `ScriptClassRootsCache` and create new one instead of resetting all internals of `ScriptClassRootsCache`. Please see KDoc of these classes for more details: - AbstractScriptConfigurationManager - DefaultScriptConfigurationManager - ScriptClassRootsCache ## Cache and up-to-date checks Writer should put related inputs snapshot for loaded configuration. This allows reader make up-to-date check for existed entry to avoid starting loading process for same inputs. Cache entry may be marked out-of-date. Also it can be marked up-to-date, but it means that we have up-to-date loaded configuration, ScriptConfigurationSnapshot.configuration will still contain old applied configuration. todo: make it more clear by splitting cache entry into loaded and applied configuration with it's own inputs. ## Loaders Previously both sync and background loaders may be started for same files - this was useful, but not required anymore and at the same time greatly complicates the model. So, it was dropped and now exactly one loader should work for given file (first applicable loader will be called). Also `ScriptConfigurationLoadingContext` is introduced to limit access to the `ScriptConfigurationManager` internals. ## Listeners and updating configuration This things is introduces: - `ScriptChangesNotifier` - `ScriptChangeListener` - `ScriptConfigurationUpdater` `ScriptChangesNotifier` will call first applicable `ScriptChangeListener` when editor is activated or document changed. (it treated as applicable if [editorActivated] or [documentChanged] will return true). Listener may call [ScriptConfigurationUpdater] to invalidate configuration and schedule reloading. Plugins may override default listening logic by adding it's oven `ScriptChangeListener`. `ScriptConfigurationUpdater` was extracted from `ScriptConfigurationManagerImpl`. ## Fixed issues and implement persistent FS cache - Script configuration was not reloaded if query for same file already in progress or ready but not yet applied - Don't start async loaders for outsider files - Unused imports: don't start loading script configuration if the result will be not applied automatically - Fix cases when virtual file can be null See `DefaultScriptConfigurationManager.reloadOutOfDateConfiguration` KDoc for more details on dealing with concurrent operations. ## Background executor and progress indicator This things changed and fixed: - progress displayed not only when we have more then 3 loading tasks, but also after 1sec of loading (including case with 1 loading task for example) - current file is displayed under the progress bar - progress indication added: it works similar to indexing indicator. When progress bar is displayed, max is fixed. When all work done for this max, progress will be started from zero and new max is fixed, and so on - cancel will drop all loading operation, not just current - concurrency issues fixed: EA-5244265 and other related to switching between silent and under progress worker See `BackgroundExecutor` for more details. ## Gradle specific behavior We have plans to extract separate implementation for Gradle scripts, but it would be better to support something at this point. For now, we have custom listener, loader and up-to-date check for default configuration manager: - listener will do forced reload on editor activation, even it is already up-to-date this is required for Gradle scripts, since it's classpath may depend on other files (`.properties` for example) - loader will force save fails before running loader. also it will skip loading if `kotlin.gradle.scripts.useIdeaProjectImport` registry key is enabled - loader will return inputs with overridden up-to-date checks: file will be considered out-of-date only when `buildscript` or `plugins` blocks are changed
Kotlin Programming Language
Welcome to Kotlin! Some handy links:
- Kotlin Site
- Getting Started Guide
- Try Kotlin
- Kotlin Standard Library
- Issue Tracker
- Forum
- Kotlin Blog
- Follow Kotlin on Twitter
- Public Slack channel
- TeamCity CI build
Editing Kotlin
Build environment requirements
In order to build Kotlin distribution you need to have:
-
JDK 1.6, 1.7, 1.8 and 9
-
Setup environment variables as following:
JAVA_HOME="path to JDK 1.8" JDK_16="path to JDK 1.6" JDK_17="path to JDK 1.7" JDK_18="path to JDK 1.8" JDK_9="path to JDK 9"
For local development, if you're not working on bytecode generation or the standard library, it's OK to have only JDK 1.8 and JDK 9 installed, and to point JDK_16 and JDK_17 environment variables to your JDK 1.8 installation.
You also can use Gradle properties to setup JDK_* variables.
Note: The JDK 6 for MacOS is not available on Oracle's site. You can download it here.
On Windows you might need to add long paths setting to the repo:
git config core.longpaths true
Building
The project is built with Gradle. Run Gradle to build the project and to run the tests using the following command on Unix/macOS:
./gradlew <tasks-and-options>
or the following command on Windows:
gradlew <tasks-and-options>
On the first project configuration gradle will download and setup the dependencies on
intellij-coreis a part of command line compiler and contains only necessary APIs.idea-fullis a full blown IntelliJ IDEA Community Edition to be used in the plugin module.
These dependencies are quite large, so depending on the quality of your internet connection you might face timeouts getting them. In this case you can increase timeout by specifying the following command line parameters on the first run:
./gradlew -Dhttp.socketTimeout=60000 -Dhttp.connectionTimeout=60000
Important gradle tasks
clean- clean build resultsdist- assembles the compiler distribution intodist/kotlinc/folderideaPlugin- assembles the Kotlin IDEA plugin distribution intodist/artifacts/Kotlinfolderinstall- build and install all public artifacts into local maven repositoryrunIde- build IDEA plugin and run IDEA with itcoreLibsTest- build and run stdlib, reflect and kotlin-test testsgradlePluginTest- build and run gradle plugin testscompilerTest- build and run all compiler testsideaPluginTest- build and run all IDEA plugin tests
OPTIONAL: Some artifacts, mainly Maven plugin ones, are built separately with Maven. Refer to libraries/ReadMe.md for details.
Building for different versions of IntelliJ IDEA and Android Studio
Kotlin plugin is intended to work with several recent versions of IntelliJ IDEA and Android Studio. Each platform is allowed to have a different set of features and might provide a slightly different API. Instead of using several parallel Git branches, project stores everything in a single branch, but files may have counterparts with version extensions (*.as32, *.172, *.181). The primary file is expected to be replaced with its counterpart when targeting non-default platform.
More detailed description of this scheme can be found at https://github.com/JetBrains/bunches/blob/master/ReadMe.md.
Usually, there's no need to care about multiple platforms as all features are enabled everywhere by default. Additional counterparts should be created if there's an expected difference in behavior or an incompatible API usage is required and there's no reasonable workaround to save source compatibility. Kotlin plugin contains a pre-commit check that shows a warning if a file has been updated without its counterparts.
Development for some particular platform is possible after 'switching' that can be done with Bunch Tool from the command line.
cd kotlin-project-dir
# switching to IntelliJ Idea 2018.2
bunch switch 182
Working with the project in IntelliJ IDEA
Working with the Kotlin project requires at least IntelliJ IDEA 2017.3. You can download IntelliJ IDEA 2017.3 here.
After cloning the project, to import the project in Intellij choose the project directory in the Open project dialog. Then, after project opened, Select
File -> New... -> Module from Existing Sources in the menu, and select build.gradle.kts file in the project's root folder.
In the import dialog, select use default gradle wrapper.
To be able to run tests from IntelliJ easily, check Delegate IDE build/run actions to Gradle and choose Gradle Test Runner in the Gradle runner settings after importing the project.
At this time, you can use the latest released 1.2.x version of the Kotlin plugin for working with the code. To make sure you have the latest version installed, use Tools | Kotlin | Configure Kotlin Plugin Updates and press "Check for updates now".
Compiling and running
From this root project there are Run/Debug Configurations for running IDEA or the Compiler Tests for example; so if you want to try out the latest and greatest IDEA plugin
- VCS -> Git -> Pull
- Run the "IDEA" run configuration in the project
- a child IntelliJ IDEA with the Kotlin plugin will then startup
Including into composite build
To include kotlin compiler into composite build you need to define dependencySubstitution for kotlin-compiler module in settings.gradle
includeBuild('/path/to/kotlin') {
dependencySubstitution {
substitute module('org.jetbrains.kotlin:kotlin-compiler') with project(':include:kotlin-compiler')
}
}
License
Kotlin is distributed under the terms of the Apache License (Version 2.0). See license folder for details.
Contributing
Please be sure to review Kotlin's contributing guidelines to learn how to help the project.